You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Grouper Solution to the CMU Billing Use Case

Namespace

First create a section of the folder namespace for this application, e.g.

edu:cmu:it:apps:billing

GSH (note, you could do this with UI/WS too):

Grant that folder to the development team for this application, and for the service principal the application uses to access the deployment of Grouper.  I recommend making an admin group for this application, and adding that group to the the proper privilege lists.  e.g. edu:cmu:it:apps:billing:groups:admins

GSH (note, you could do this with UI/WS too):

Roles

The application would need the following roles:

  • edu:cmu:it:apps:billing:roles:universityBillingAdministrator
  • edu:cmu:it:apps:billing:roles:student
  • edu:cmu:it:apps:billing:roles:studentDelegate
  • edu:cmu:it:apps:billing:roles:localBillingAdministrator

GSH (note, you could do this with UI/WS too, though you might need GSH to switch types to Role)

Note that security  for who can read those roles, or assign, would be given to the group edu.cmu.it.apps.billing.groups.admins.

GSH (note, you could do this with UI/WS too):

You might assign the student role to the cmu overall student group (e.g. edu:cmu:community:students).  Then as new students are provisioned into that group from the student system, they will automatically be assigned the role in this application.  And as students fall out of the overall students group, they will lose the role in this application.  If there are exceptions, you can make a group that is Grouper includeExclude so that you can have additions or restrictions from the system of record group.  The students group could be provisioned via the Grouper Loader, or other means.

GSH / SQL (note, the Grouper commands can be done with the UI / WS / client).  Create the students group, synced from a source system (simulated by using a static sql table)

Make the studentRole an includeExclude, and add the student group to the system of record part.  This means that generally students in the students group have the role, though you could ad hoc add or subtract from that withotu affecting the loaded group.  This can also be done with the UI, WS, or client

For the university wide billing administrator and the local billing administrator roles, you should probably create a Grouper restrictGroup where you look at what the person must be to have the role.  If what they must be is an active staff member, then setup the restrictGroup so that if the user ever stops being an activeStaff member, they automatically fall out of the university or local billing administrator role.  If it is wider, then make it an active CMU member, etc.

GSH / SQL (note, the Grouper commands can be done with the UI / WS / client).  Create the employees group, synced from a source system (simulated by using a static sql table)

Make the localBillingAdministratorRole and universityBillingAdministratorRole a requireGroup, and add the employee group as the "required" group.  This means that if a user who is a local or university admin, then if they are ever not an employee anymore, then they will fall out of the overall group and also not have their permissions anymore.  This can also be done with the UI, WS, or client

Assignment to the universityBillingAdministrator role could have start and end dates, or could be provisioned with workflow and approvals.

Permission resources

There are two tracks of permission resources, the ones specific to this application, and potentially the re-use the organization-wide org chart.  If the school has a university wide org chart of resources which matches the requirements, it can be re-used.  This is what Penn is doing.

So the org chart looks like this:

edu:cmu:community:resources:orgs:UNIV:USCH:02XX
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:CGSP
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:CGSP:CGSM
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:CGSP:CGSM:0174
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:CGSP:CGSM:2108
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB:BIOL
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB:BIOL:0103
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB:BIOL:0105
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB:BIOT
edu:cmu:community:resources:orgs:UNIV:USCH:02XX:BIOB:BIOT:0333

And there is a hierarchy where if you are assigned CGSP, then you also have the decendents of that node.  Note, grouper can help manage the hierarchy table if the org list exists.  Documented here

Allow the app admins to read and/or assign these privilege resources.  To keep things simple, we will use the university admins, though could be a different group/role

Limit the assignments of this permission to the local billing admin role

The permission resource should have READ/WRITE action options

Lets assign this permission to some individuals:

Create the other permissions in the application

The permission resource should have READ/WRITE action options
gsh 55% billingPermissionsDefinition.getAttributeDefActionDelegate().configureActionList(GrouperUtil.toSet(newObject[]

Unknown macro: {"read","write"}

));This definition has several resource names associated with it, e.g. my own bills, all bills, and delegate

For the delegation, we could pack the id of the user you are the delegate of into the permission resource name, or you could just put an attribute on that permission assignment.  Lets go the route of the attribute on the assignment just to show how to put metadata on permission assignments (e.g. scopes, time range, ip address, etc).

This is the attribute definition for that attribute

 So when a student wants to delegate the viewing of bills, they click the button on the screen to delegate, and:

  • The system sees if the user to be delegated to, has the role: edu:cmu:it:apps:billing:roles:studentDelegate
    • If not, assign that role to the uesr being delegated to
  • The system sees if the student delegating from (whose id is 12341234), has a permission resource in the right folder:
    • edu.cmu.it.apps.billing.permissions.students.12341234
    • If that resource doesnt exist, create it
  • The system will assign that resource to the user being delegated to in the context of the role: edu.cmu.it.apps.billing.roles.studentDelegate

When specifying a local billing administrator, the system wide admin would assign the role edu.cmu.it.apps.billing.roles.localBillingAdministrator to the user, and will assign READ to one of the orgs in the global shared org chart.

Note: a privilege resource assignment in Grouper can be marked with a delegation flag of T (true), F (false), or G (grant, it is true, and the recipient can grant the delegation flag to whom they delegate to).  Not sure if this is useful for this application or not.

Checking permissions

Currently as of 11/3/9, the only permission management interfaces from Grouper are SQL (definitely), and LDAP (theoreticall), but we will be building web services soon.  The application will either need to check permissions dynamically, or export all the relevant permissions periodically, or for a user on their login.  If there are SQL joins e.g. to list all the students someone can VIEW, then you might need the 2nd or third option to get all the data together.  The following decision making process needs to occur:

Can user X see bill for user Y:

  • If user X has permission: edu.cmu.it.apps.billing.permissions.viewAllBills in the role edu.cmu.it.apps.billing.roles.universityBillingAdministrator, then the answer is YES
  • If Y user is the same as X, and X has edu.cmu.it.apps.billing.permissions.viewOwnBills in the role edu.cmu.it.apps.billing.roles.student, then the answer is YES
  • If Y has the ID of 99887766, and X has the permission READ for edu.cmu.it.apps.billing.permissions.students.99887766 in the role edu.cmu.it.apps.billing.roles.studentDelegate, then the answer is YES
  • Find the orgs that user Y is associated with.  Assume it is org A:B:C, and D:E:F.  See if X can READ either edu.cmu.community.resources.orgs.UNIV.USCH.A.B.C or edu.cmu.community.resources.orgs.UNIV.USCH.D.E.F for the role: edu.cmu.it.apps.billing.roles.localBillingAdministrator.  If so, then the answer is YES
  • Else, the answer is no.
  • No labels