perMIT and the selected use cases

Course Deadline Extended

Old and New Payroll Clerks

Dorm Access for Residential Advisors

Professional Organizations and Federations

Drug Restocking Approval

Delegated Directory Administration

Course Deadline Extended

(read use case)

In order to keep the discussion simple, lets assume that the ASPECs for the course look something like:

In reality, each ASPEC also has a starting and ending date. Given an LMS that behaves as described in the use case, ASPECs would have been created for each student in the class, and the starting date would have been the start of the semester, and the ending date would have been defined as the end of the semester.

Dr. Schonfeld would also have been given the grantor privilege for each of the functions associated with category, for the qualifier of "(in)  Ordinary Differential Equations". Therefore Dr. Schonfeld would go to the UI and modify the ending date of Sally's ASPEC, extending it by an additional week. Once the end date was reached Sally would no longer have the "is a student" privileges in  Ordinary Differential Equations, just as all of her peers had experienced a week earlier.

Note that a typical LMS will actually have a much richer set of functions. It will likely use function inheritance, whereby the "is a student" function will result in several other functions being granted to the student. It's possible that one of the child functions could be "take final exam", or "access final exam materials". In that case Dr. Schonfeld might decide to drill down to the child functions and only extend the date on a subset of the child functions.

Old and New Payroll Clerks

(read use case)

The perMIT response to the "Old and New Payroll Clerks" use case will map the use case to how perMIT is being used at MIT to meet very similar needs.

From the use case, let's assume that the department chair in the Department of Chemistry is the HR Primary Authorizer and Financial Primary Authorizer for the department. This means that the department chair has the ability to grant any HR or Financial related functions that apply to qualifiers within the Department of Chemistry.  (Editorial comment, in reality these functions are probably not assigned to the department head and are instead assigned to someone in the Dean's office of the School of Science. For example the Assistant Dean of Science, or the Assistant Dean for Finance within the School of Science.)

HR Primary Authorizer

Financial Primary Authorizer

So the ASPEC used to manage the privileges of Marcus and Gina is:

MIT does not have a function named "Payroll Clerk".  All of the functions defined for the payroll category can be viewed at http://rolesweb.mit.edu/cgi-bin/rolefunc2.pl?category=PAYR+Payroll

http://vpf.mit.edu/site/payroll/policies_procedures/salary_certification_policy/4_0_salary_distribution_roles_and_authorizationsexplains some of the terms in detail. For example:

EDACCA Administrator - a DLC (Department, Lab or Center) administrator who is authorized to electronically certify the Quarterly Salary Distribution Report by proxy and who is responsible for retaining supporting documentation signed by the certifier. The eDACCA Administrator can be authorized to access % only, or % and dollars. Authorization granted at the following levels:

• Profit Center Group
• Profit Center
• Profit Center/Cost Object Supervisor
• Cost Object
  

eDACCA certifier - an individual with direct knowledge of the work performed who is authorized to certify the DACCA without maintaining paper back up. The eDACCA Certifier can be authorized to access % only or % and dollars. Authorization granted at the following levels:

• Profit Center (rare)
• Profit Center/Cost Object Supervisor
• Cost Object
  

eSDS Administrator - is authorized to access and update salary distribution records. There are two roles for distribution maintenance - one for appointments in the HR Org Unit and one for transfers in. Both roles may be granted with the ability to see salary or not. Distribution authorizations for appointments in the HR Org Unit are granted for the entire HR org unit. Transfer-in distribution authorizations may be granted at the following levels:

• Profit Center Group
• Profit Center
  
  
  

Since Gina and Marcus will need access to sensitive payroll information about non-exempt employees in the department, but will not need access to faculty salary information, we will assume that some of the existing ASPECs are

But some of the employees in the department also submit traditional timesheets, so another ASPEC is

Note that the qualifier data type in the ASPEC s above are not an ORG unit, instead one is a payroll time group, the other is a cost object. Since different functions associated with the job of "payroll clerk" use different qualifier data types, we can't simply define a new function named "payroll clerk" and use simple function inheritance to create the ASPECs for  EDACCA CERTIFIER-PERCENT ONLY,  TIMESHEET ADMINISTRATOR and the other functions.  However, it is possible to do something like this using perMIT's Implied Authorizations. In reality this is not done, because the exact business practices of who should have exactly what fine grained payroll permissions in each department is not uniform.

Presumably Gina also deals with some other aspects of the financial work within the department. For example, she probably runs financial reports to look at  do detailed  charges against one or more cost objects.  So Gina will also have some ASPECs that are in the financial category, instead of payroll:

But since the department chairman does not want Gina (or Marcus) to have the ability to look at faculty salaries, she will NOT be given the function qualifier pair:

We have all of the ASPECs, and many others, defined for Gina. But our department head wants to give Marcus these privileges and remove them from Gina. Doesn't this sound like a lot of data entry? Well, the department head doesn't actually have to do a lot of data entry.

In the UI he can say that he want to look at all ASPECs, assigned to Gina. He can then click on each one that he wants to grant to Marcus, enter Marcus' name into one field and hit the button that says "reassign selected". In other words he can make the reassignment happen as one bulk operation by clicking on some check boxes, typying Marcus' name once, and clicking on one button. If he wants Gina to have these privileges for a short period of time that overlaps with Marcus, he can instead select "copy selected".

When the feed from HR indicates that Gina has changed departments, the department chairman will receive a report showing all of the ASPECs that he ever assigned to her, and remind him that she has changed jobs. Presumably, he will determine if there are other privileges that he should transfer to someone else at that time. Also, he might decide to delete all of those ASPECs at that time. If he takes no action within 30 days, the ASPECs will be deleted. If he would like Gina to retain some of the privileges that he granted, he can extend the ending time of the ASPEC.

Dorm Access for Residential Advisers

Create a qualifier hierarchy that includes all of the dorms, and living areas, which have a door access system that has card readers.  Example

• All
• East Campus
  • Zone 1
    • Pegram
    • Bassett
    • Alspaugh
    • Brown

• • Zone 2
    • Giles
    • Wilson
    • Jarvis
    • Aycock
    • Epworth

• • Zone 3
    • Randolph
    • Blackwell
    • Gilbert-Adams
    • Southgate
    • Bell Tower

• West Campus
  • Zone 4
    • Kilgo
    • Crowell
    • Craven
    • Few

• • Zone 5
    • Keohane
    • Edens 1a
    • Edens 1b
    • Edens 1c
    • Edens 2a
    • Edens 2c
    • Decker
    • Mitchell
      
      

Only one function needs to be created for this use case, "Is Resident".

Create data feeds and implied authorizations to instantiate ASPECs for each student in campus housing and for each RA. For Students, the qualifier will actually be the residence that they are living in. The data fees will take into account the information from the housing office (which has specific room assignments), the Office of Residential Life (which determines who is an RA), and the registrar (which knows who is registered student and who is on leave of absence).

For RAs the qualifier will be the Zone that they are living in, or assigned to.

Example ASPECs:

The door access system will make two types of queries to the perMIT system. Between the hours of 8am and 10pm, the system will ask if the subject is a resident, however the qualifier will be NULL. The date being asked about will be the current date.

Since the qualifier is NULL in this query, any subject that has the function "is resident" assigned to them, and their starting and  ending dates for the ASPEC include today, the response will be YES. Suppose Richard tries to enter Randolph at 9pm on 10/1/2009. The query will look like:

• DOOR-ACCESS, Richard, IS RESIDENT, NULL, 10/1/2009 and the response will be YES.
  

If the person's ASPEC has expired, or the person doesn't have the "is resident" function assigned to them, the system will respond NO, and their access will be denied.

If Max tries to do the same thing, the query looks like:

• DOOR-ACCESS, Max, IS RESIDENT, NULL, 10/1/2009.
  

Since Max was only granted this function from 9/1 to 9/2, the response is NO.

Between the hours of 10pm and 8am, the door access system will not use a NULL qualifier. Instead the qualifier will be the dorm where the specific card reader is located. If Richard tries to enter Randolph at 11pm on 10/1/2009, the query will look like:

• DOOR-ACCESS, Richard, IS RESIDENT, Randolph, 10/1/2009 and the response will be NO.
  

However, if Richard tries to do the same thing on 10/16/2009 the same query will be made, but the answer will be YES. This is because Richard is not only a resident of Kilgo, but he also has another ASPEC which says he is a resident of Zone 4, which includes both Kilgo and Randolph.

Professional Organizations and Federations

(read use case)

I have a concern with the language of the use case. In particular it closing statement which says, "The web application subsequently determines whether to grant them access...(as determined by direct inspection of the ALA's membership roster). It appears that the language used in the use can be interpreted to dictate the solution to the problem. The perMIT response to the use case will ignore the dictated solution and instead focus on how perMIT could be used in such a scenario.

We'll ignore what privileges are implied by being a proctor of the survey, or what privileges may be required to read the summary results, see the raw results, see who provided responses to the survey, etc. Instead we'll focus on managing the privilege which determines if an authenticated individual can respond to the survey.

So we'll call the function RESP-SURVEY.

The qualifier in this case will simply be an identifier for the survey. This is useful instead of using a NULL qualifier since the ALA operates multiple surveys each year.  The identifier for this survey will be 100115-eps.

Next we need to decide what to use as the subject for the ASPECs.

The ALA maintains an LDAP directory which contains the following information about its members:

• First Name (self asserted when the user joins)
• Last Name (self asserted when the user joins)
• Title (self asserted when the user joins)
• Org/Company (self asserted when the user joins)
• City (comes from billing information provided by user when joining, home or office)
• State (comes from billing information provided by user when joining, home or office)
• Email address (self asserted when the user joins)
• Type of membership:
  • Regular, student, library support staff, non-salaried membership, retiree, trustee, friend, associate, international, life, and continuing. 

We know from practical experience that self asserted first names and surnames often are not an exact match with the first names and surnames that an enterprise will have in their system of record. Furthermore, we cannot guarantee a unique identification based on the first and last names even if we could be confident that both systems had canonical values.

We'll use the email address as the subject identifier for the ASPECs. Note that some of the ALA members that are in the higher-ed community might not have provided their higher-ed email address to the ALA. Instead the user's may have provided a gmail, hotmail, or other account to the ALA.

Although the ALA provides a web form for their members to update their directory information, members may wish to receive email from the ALA at a personal email address. The ALA may wish to provide a new form which allows their members to indicate the value that their organizational IdP will use to identify them, and that is separate from the email address which they prefer to receive communications from the ALA.

A connector is written to extract data from the ALA LDAP directory and with perMIT's "implied authorization" subsystem ASPECs are created for:

• Each member of type:
  • Regular, library support staff, non-salaried staff, life, and continuing

Although the Federation which the ALA belongs to also includes organizations which are not colleges or universities, the ALA decided not to use their Org/Company data to limit the creation of the ASPECs for this survey. They are intending to use their experience with this survey to determine if they have a data quality problem related the Org/Company information in their directory.

We end up with ASPECs that look like:

The web survey application will require users to authenticate via the federation. The federation IdPs will be required to release the email address to the survey application. The survey application will take the asserted email address and make a simple web service call to determine if the user is permitted to respond to the survey.

If the user is not permitted, the application will inform the user and ask the user if they would like to update their ALA directory information. If the user wishes to do so, the user will have to log into the directory maintenance application using their ALA username and password.

Drug Restocking Approval

(read use case)

After many years of false starts the medical school and the teaching hospital are leveraging the campus's identity services, however, they do not leverage the newly installed enterprise workflow system. Instead they have their own workflow system. The privileges for the pharmacy system are managed in their own category within perMIT. The category is simply named PHARMACY.

There are a number of different functions and qualifier types within the PHARMACY category. Some of the qualifier types express the financial structure of the hospital and medical school. Some of the qualifier types express the organizational model, for the sake of the use case let's call this the ORG hierarchy. Each ward of the hospital appears on one of the branches of the ORG qualifier hierarchy.

We'll define the following functions which accept the ORG hierarchy as qualifiers:

REQUEST RESTOCK

SUPP APPROVER

ATTENDING APPROVER

PHARMACOLOGIST

REPORT by ORG

REPORT by Attending

REPORT by Nurse

The hospital has decided to use one year time periods by default for normal privilege assignments. This forces a re-evaluation of the privileges even if the person's department or job title has not changed.

The following ASPECs are defined for this use case:

perMIT doesn't track which drugs are scheduled substances, that information is part of the Pharmacy application. When Nurse Wilson places a restock request, the web service is called to determine if she has the necessary privilege.  The pharmacy system will see that she has the necessary privilege but determine that the request is for a scheduled drug. It will then route to Nurse Wilson's supervisor, (Nurse Ratchet).

When Nurse Ratchet uses the pharmacy system she will see that she has a list of approvals to perform. When she attempts to perform the approvals, the pharmacy system will once again call the perMIT web service to determine if she is authorized, at this time. Note that the routing of the approval is decoupled from the privilege enforcement.

Once Nurse Ratchet has made the approval the pharmacy system will route the request to all of Oncology's attending physicians. Dr. Fine happens to be the first one to look at his queue. When he attempts to approve the request, the web service is called by the application to determine if he currently has the necessary privileges.

Presumably at this point the pharmacy system routes the request off to whomever needs to make the financial approvals to fulfill the request.

Delegated Directory Administration

(read use case)

The school where Bill works is a complicated organization. One that values cross discipline collaboration. It is not unusual for faculty members to have dual appointments across Departments, Labs, and Centers.

The IT staff at Bill's university decided that the organizational complexities would create many conflicts with an AD deployment that was modeled on the traditional HR org chart. Instead the IT staff decided to create a very simple, flat organization that contains all of the people in the university. It then created a richer OU for machine resources. Within the OU for machines, sub OUs  for Departments, Labs, Centers, Projects, and experiments can be created as needed, at the discretion of the central IT department.

In order to support such a free-form collaborative environment, the choice was made that the standard Microsoft tools would not be used in all cases. Instead, a set of simple web applications were created to help automate some of the simplest repetitive tasks. The web applications allow the central IT department to delegate a variety functions to a wide variety of people, at the granularity chosen by the central IT group.

One of the tools created lets end users delegate their account administration to others. Remember, all of the user accounts appear in the same single OU, so we can't simply move an account and expect AD inheritance determine  who has the ability to administer the account. Instead, a faculty member could go to web application and choose Bill as his Windows account administrator. Or he could indicate that the Dept. of Chemistry could administer his account. Or one can even imagine that he might indicate the group of Windows system administrators for the Dept. of Chemistry could administer his account.

Although the idea of placing the responsibility of this choice on the end user eliminate many political problems within the organization, it also creates work for everyone. To address this, IT also creates a business process which enables a department chairman to designate someone that can make such decisions for the department. Note that the person so designated can say that anyone at the university falls under his dominion. There is no technology in place to prevent potential abuse. The risk for abuse is mitigated by audit trails and accountability to his or her boss.

Back to the use case. Bill has been designated by the department chair as a person who can say which accounts he can administer. Bill provides the list of account names to central IT, via a group management system. A perMIT rule is then written which then instantiates ASPECs for each of the users on the list. In this case the users on list are Qualifiers, not the subjects.

(Note the CA prefix in this case just means Can Administer.)

Because users can log into machines in any department, and not just the department of Chemistry, the values of the user's homeDirectory and homeDrive attributes are actually derived from the name of the user's home server. Bill can administer the Department of Chemistry's file servers to his heart's content, however, there are certain conventions that he must follow. This ensures that domain wide pre-login, login, and post-login scripts operate in a consistent manner, no matter which machine a particular user logs into during the day.

When Bill migrates his users to a new departmental file server, he will simply update the name of server for each of the user. (The web application will also take a flat file, or a list name as input.) For each one of the users, Bill's privilege to make this change will be checked. If it is granted, the web application will update all of the corresponding attributes in AD. Bill does not need to know the details of the AD schema, the application does. Bill simply needs to know how to operate a Windows server, and follow some simple directory naming conventions on his server.

In this case, Bill is never given the opportunity to attempt to change any of the attributes relating to Exchange for the users that he is managing.

However, the strategy outline above also lets central IT delegate certain privileges to people around the campus, even when the application was not designed to support delegated administration. (For example Exchange 2000.)

When Bill's file server is destroyed while he is away from campus, central IT still  has the ability to relocate the user's home directories to a new server since as AD administrators they still have the ultimate control.

However, let's also suppose that Bill had already granted Robert, a Windows administrator in the School of  Biology, the CA-homeserver privilege to all of his users for the duration of his vacation. Then Robert could simply move all of the Chemistry department users  to one of Biology's servers until Bill returns from vacation.

Bill could do this very easily. He would simply ask the UI for all of his authorizations with the function CA-homeserver and indicate that he wished to copy them to Robert effective on  2/12/2010 and lasting until 2/22/2010.