Update and expand access control models

ACM1 Grouper Subject Attributes

Eduperson affiliation / traditional shib SP IDP attribute release model

• This is not the “GO TO” model
• We want to stress policies instead of this approach
• Policy admin is pushed to the SP in this model
• Administering policy per service on grouper side is preferred 
• Using Grouper to master a subject attribute , eduperson affiliation and using shib and SAML to communicate that to the target service, then target service handles access control
• Chris: there was question about this at last training.  
• Some software as a service wants an affiliation
• But don’t want a policy group shared across  affiliation
• This approach could address  that
• Need to explain better how to use this model
• Only do this if you have to
• Don’t have different definitions per ref group per service

 

• Advice should be to:
  • Try to keep ref groups stable
  • Build policy from those stable ref groups
• If loose coupling and SP is happy with whatever definition for subject attribute, then it’s easy to deploy 

•   tickets use case at Lafayette
• Loose affiliation w software as a service used for tickets
• If student , then they get the discount
• Easy to implement
• Would prefer access control model 2 if were reimplementing this now

===========

ACM2 Grouper as PAP and PDP

• This is the golden model, gets most value
• Policy per service
• Leverages power of Grouper in terms of delegated admin 
• Can use point in time to see who had access
• Helps keep ref groups stable

===========

ACM3 RBAC User to Role Mapping

• Cases where target service has some sophisticated management interface
• Lafayette case: business intelligence system Cognos
• Long list of permissions that can be mapped to a role
• Can manually associate a user to role in Cognos
• But better to use Grouper
• So  split policy admin between target service (Cognos) and Grouper
• So ACM3 is an extension of ACM2
• If off the shelf app has 3 roles built in, you may want to use ACM 2. 
• But ACM3 may be better if you can configure what the roles can do in the application,  Confluence is an example 
• Policy is split in ACM3 

===========

ACM4 WebSSO Short-circuit

• Leverage Shib IDP to enforce access control. If you don’t have control over the target, here is another way you can do it
• ChrisH: Please mention that the “coarse grained” can be a much wider net than the app needs.  I.e. if its only 200 people and the coarse grained is “employee” with 10k people, that might be ok
• Please mention the PEP can be the IdP, or a load balancer (can do it with F5), or with a reverse proxy like apache, or with SP, or with application
• If target service does not have a good user experience
• If it will blow up in your face in some cases
• Could implement with reference groups, etc. but implementation is slightly different

 

===========

Comments on the ACMs

• Note that ACM2, ACM3 and ACM4 are similar. 
• ACM2 and ACM3 are quite similar
• ChrisH suggests that we merge ACM2 and ACM3
• With ACM3 there are 2 parts of the policy, who is in the role and what the role can do
• Suggestion for ACM5, you can do RBAC inside of Grouper,  mainly used for Custom applications. 
• ACM 6, is important, some apps are not conducive to externalizing , you can take those apps, get a feed or roles and permissions , load into Grouper and you can get reports, can get emails for manually unassign, 
• State that you can do multiple access control approaches, depending on the target, you can mix and match 
• BillT: yes could add ACM 5 and ACM 6

 

• AndyM: Should the order we introduce the access models be considered? Maybe leading with the "gold standard" or leading with the least-capable model.  Could be ACM2, ACM3, ACM1, ACM4 (gold standard first) or ACM4, ACM1, ACM2, ACM3