Access Control Models

Overview

The overall approach to access management with Grouper is to create and maintain access policy groups which are built from institutional meaningful cohorts (reference groups), ad hoc exception groups, and indirect basis groups . 

The next step is provisioning the policy group memberships to the target service.  This can be done in various ways, but it is preferable to do this via LDAP or SAML.

The target service uses the information from Grouper to determine which coarse or fine-grained application permissions the user has.  This can be hard-coded in the application or managed locally in the service.  For example the user might be dynamically assigned to a group in Confluence due to a SAML entitlement, and might have access to projects due to configured access in the Confluence admin screens.  It's possible to manage application permissions in Grouper but it is not common.

How application permission sets are managed, membership assignments are communicated, and access policy is enforced can vary quite considerably depending on the security needs and capabilities of the target service. However, the overall approach to access management with Grouper remains consistent. The following sections use terminology and models from NIST SP 800-162 and XACML to demonstrate a variety of models leveraging this approach.  Note, you could use multiple models at once, or could engineer hybrid approaches.

All the Access Control Models (ACM) described lend themselves to distributed access control, meaning the authority to manage an access control policy or exceptions to policy can be delegated to authorized people.

ACM Policy groups and application static permissions

In this model, access policy administration and the policy decision point (precomputed membership assignments) are done in Grouper and can be communicated to the target service in a variety of ways. Access policy groups in Grouper enable direct mapping from natural language policy to digital policy and back, and policy is kept up to date automatically as subject attributes change. This model supports audit, compliance, and attestation. 

1. Access policy groups configured in Grouper based on institutional meaningful cohorts (i.e. reference groups, ad hoc groups, etc)
2. Policy decisions (membership assignment in access policy group) precomputed
3. Authorization provisioned to application e.g. with LDAP, SAML, WS, direct provisioning, etc
4. Application uses those role(s) to allow the user to perform actions

ACM Policy groups and application dynamic permissions

In applications with sophisticated RBAC capabilities, fine-grained permission sets are typically configured via an administrative interface within the application itself. These permission sets are then associated with a role that can be mapped to a set of users. In this model, the user to role mapping is done in Grouper by pairing a normal access policy group with the role defined at the target service. The policy of which subjects are mapped to application roles is similar to other ACMs with policy groups.  Its possible there are permissions assigned to individual users in the application.  For this reason, Grouper's view of what a user has is not the same as for applications with static permissions.  Two users who have the same role in Grouper could have different permissions in the application.  Grouper knows at a high level what the user has, but you need to consult the application for the full picture.

1. Fine-grained permission sets are managed at the target service (Role -> Permissions) and assigned a Role Name
2. Grouper access control group statically mapped to target service Role Name and provides User -> Role mapping
3. PAP split between Grouper and target service, PDP and PEP at service

ACM Policy group for coarse-grained access

Often for pragmatic reasons one wants to limit access to a target service by restricting any access to the application to a certain population.  This enabled defense in depth by providing an outer perimeter to the application and network traffic.   This could be used in many situations and is recommended wherever possible. It is preferable to use a reverse proxy and block nefarious network traffic before it reaches the application.  This ACM can be used along with other ACMs.  Several cases where this is necessary or desirable are; 1) when the target service has insufficient access controls to limit access based on the desired policy, 2) when the target service lacks a good unauthorized user experience., and 3) when the application runs on software that might have 0-day exploits and the security patches are difficult to keep up with.

The population of this group could be wider than the app needs, since the app will provides its own authz.  So at a minimum the policy group could be "employee" at the institution, even if certain employees have roles in the application.  The most precise coarse-grained policy group would contain the union of all roles in the application.

Of course this ACM does not absolve the application from also having to do other forms of access control (e.g. identify the admin users).

There are several options for the policy enforcement point (PEP) to restrict access

1. PAP: Access policy groups configured in Grouper based on institutional meaningful cohorts (i.e. reference groups)
2. PDP: Policy decisions (membership assignment in access policy group) precomputed and reflected into LDAP based enterprise directory as LDAP groups or eduPersonEntitlement values.
3. PEP: WebSSO flows honor policy decision by short-circuiting authentication flows to an a generic or application specific “unauthorized user” page. 

ACM: Grouper for access reporting

It is ideal if Grouper can be system of record for authorization.  But in many cases it cannot be.  This could be because the application cannot use external roles, or because the application is preferred to manage those things internally (e.g. the UI in the application is needed for use).  In this case hopefully you can feed authorizations in the application, or just who has any authorization, into Grouper group(s).  Now when you go to Grouper and see what someone has access to, you can see that application in the list.

Loading application authorization to Grouper needs to be a regularly schedule task so the data does not diverge

1. Grouper loader via SQL or LDAP (preferred)
   1. You could ETL the data to a SQL or LDAP first
2. Web services
3. Custom job
4. Manual process (e.g. export the authorizations to CSV and import into Grouper.  Do this periodically (e.g. monthly)

Once the authorizations are in Grouper you can use Grouper reporting, rules, attestation, deprovisioning, auditing, etc.  This data in Grouper is readonly since it is sourced and managed in the application.  In this case deprovisioning or attestation must involve a user using the application to remove the authorizations.

1. Authorizations are managed in the application
2. Authorizations are loaded into Grouper
3. Create policy groups similar to other ACMs
4. Convert those groups into roles
5. Configure permission resources and assign to roles / users
6. Provision roles/permissions to application

ACM: Grouper managed permissions

All of the access control models discussed so far assume the target application has some mechanism to manage application specific permissions. This could be a fairly static application roles to permissions mapping, or a sophisticated RBAC like system one might find in ERP or business intelligence system. 

While mostly out of scope for this guide, Grouper does have an advanced RBAC system that is suitable for externalizing application permission management. In this model, the target system relies on Grouper for application permission management, including permission definition, role and resource hierarchies, and role to permission mapping. 

Grouper role and permission management provides more details on this advanced use of Grouper.

1. Create policy groups similar to other ACMs
2. Convert those groups into roles
3. Configure permission resources and assign to roles / users
4. Provision roles/permissions to application

ACM: Reference group authorization

In this model, Grouper is used to master subject attributes that represent some type of affiliation or status at the institution.  Generally these are reference groups for member, student, employee, etc.  Actual access policy is completely local to the service, and the availability of an agreed upon subject attribute is sufficient to make a policy decision.   This model was common years ago before authorization systems like Grouper existed.  It is not recommended to do this since you are back to reference groups without the flexibility of policy groups.

This model is useful for cases when there is an informal relationship between the institution and the service provider, and a locally defined notion of the subject attribute like eduPersonAffiliation is sufficient for access control. However, the model breaks down quickly if a more exact notion of the subject attribute is required or if it needs to be different across services. It is important to remember that cohorts (affiliations, status, class year, etc) are not access policy. Do not be tempted to create service specific versions of cohorts as reference groups.

Its possible that a service requires the eduPersonAffiliation of student.  The population that the SaaS application needs might not be exactly what the institutional "student" reference group contains.  You could configure your IdP to map a policy group for that application to that affiliation only for that application.  This obviously has its downsides however (e.g. it can be confusing to troubleshoot/maintain).  Document well.  

1. Subject attributes like eduPersonAffiliation are mastered in Grouper
2. The affiliation(s) are passed to the target service via SAML or queried via LDAP after authentication
3. The service allows access or uses the affiliation to map to a role / permission set