There are several ways that one could satisfy the CMU Billing Use case using perMIT. This document will attempt to outline a couple of different approaches.
Without Rules
Without using rules driven privileges, or what perMIT has been calling Implied Authorizations, it is possible to support most, if not all of the CMU Billing Use Case.First, you could define the following:
Function name = VIEW STUDENT BILLS BY DEPT
Qualifier type = Academic org unit
ASPECs can then be assigned to allow an administrator in a given department to view student bills for any student within that department. The University-billing-adminsitrator(s) would be defined as the people that have been assigned this function with qualifier that exists at the root of the qualifier hierarchy. The University-billing-administrator(s) would also be given the ability to grant this function to others. The University-billing-administrator(s) can then create Local-Billing-Adminsitrators by granting the function to others and specifying the appropriate qualifier in the heirarchy.
Presumably, these authorizations would be widely viewable, since names of departmental administrators in various departments are already widely known. Also, in the case of students associated with more than one department, it seems likely that a departmental administrator from one department will at times find it necessary to determine which peers from another department may be reviewing the same bill.
To look up Authorizations for this Function, the application would specify a target user (who wants to view the bill?) and a department code. The application would have to know the department code or codes associated with the student who has a bill that someone wants to view. Next you would also define: Function name = VIEW INDIVIDUAL STUDENT BILL
Qualifier type = Students/Bills
ASPECs would be assigned for access to all student bills for a given student-ID, or potentially even for a particular bill number associated with a student, if such fine granularity was required. Presumably these authorizations would be less widely viewable. This could be accomplished by putting this function in a different category than VIEW STUDENT BILLS
BY DEPT. perMIT also provides the ability to make the qualifier type sensitive, thus restricting access to view the hierarchy that contains student numbers and bill numbers. The Students/Bills hierarchy would start at the root, go down to schools, have departments under each school, students under each department, years under each
student, and bill numbers under each year. perMIT does not require qualifiers to fall under a strict hierarchy, and in this case you would take advantage of that flexibility by allowing a
student-ID to fall under more than one department in cases where a student has a double major. If bills are department-specific, then you could have objects in the hierarchy that represent student-dept pairs, and individual bills would be attached to
student-dept pairs rather than just to student-IDs. At MIT we do something similar with our Environmental Health and Safet Principal Inevestigator/Room-Set (EHS PI/Room-Set)
hierarchy in which we have objects that represent PI-department pairs rather than just PI objects.
To look up Authorizations for this Function, an application would specify a target user (who wants to view the bill?) and a bill ID or student ID.
Using Rules
perMIT also provides a way to use rules, combined with enterprise data to populate the ASPECs. Conceptually this is similar to Grouper's combination of the "systems of record" and the "Grouper Loader". There are several ways that this functionality could be used to meet the CMU Billing Use Case.
It is possible that some sites will have data in a system of record that can be used to detemine exactly who becomes a Local-Billing-Administrator. This would relieve the burden from the University-Billing-Administrator of managing the ASPECs used to control who is a Local-Billing-Administrator.