Access Control Models

Overview

grouperGdgAcmHighLevel

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 access policy groups are provisioned and mapped to coarse or fine-grained permission sets at the target service.

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 fine-grained application permissions the user has. This is generally 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 by configured access for the group 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 models 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.

Access Control Model	Type	Description	When to use	Notes
Policy groups and application static permissions	Policy groups	This is a very common access control model	If the application has hard coded permissions based on roles, and roles can be provisioned from Grouper
Policy groups and application dynamic permissions	Policy groups	Very similar from a Grouper perspective to "Policy groups and application static permissions"	If the application can configure permissions based on roles, and roles can be provisioned from Grouper
Policy group for coarse grained access	Coarse grained	Identify the population of who should be able to log in to the application, make a policy group, and lock out users not in that group	Use this for local or SaaS applications. This drastically improves your security posture. Use this if you cannot integrate roles with the applciation, or even if you can!	This can be setup as a reverse proxy to protect the application from any unauthenticated, unauthorized access
Grouper managed permissions	Externalized permissions	Policy groups are used as roles in Grouper by assignments permissions in Grouper to the roles/users. Permissions are provisioned to the application	For custom application where you want to offload the permissions to Grouper as an RBAC engine	The difficulty can be if the app can support externalize permissions, if the grouper RBAC permission model fits the application, and if the generic Grouper screen are usable for the application
Grouper for access reporting	Access reporting	Access is configured in the application. Assignments in the application are loaded into Grouper to help with reporting and deprovisioning	Use this if the roles/permissions in the application cannot be externalized to Grouper. Its very valuable for Grouper to track the assignments.	You can use Grouper attestation, Grouper deprovisioning, etc on readonly access assignments
Coarse-grained reference group authorization	Reference groups	Use eduPersonAffiliation or equivalent to secure access e.g. based on if the user is a student or employee	Use this if the application (SaaS?) only supports security by eduPersonAffiliation	Less mature, less flexibility, not recommended You could workaround this it might not be ideal

ACM2 Grouper as PAP and PDP

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 enables 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. It applies to both coarse-grained access control and limited/static application roles.

PAP, PDP done in Grouper - PEP done at SP

PAP: Access policy groups configured in Grouper based on institutional meaningful cohorts (i.e. reference groups)
PDP: Policy decisions (membership assignment in access policy group) precomputed and reflected into LDAP based enterprise directory as LDAP groups or eduPersonEntitlement values.
PEP: Policy decision communicated to the PEP at the target service via SAML, LDAP query, Grouper WS query, or directly provisioning to the service.

Figure 8: Access Control Model 2 - Grouper as PAP and PDP

ACM2 is applicable across a broad range of services where access control policy can be based on subject attributes, the policy decision can be precomputed, and simple subject attributes are sufficient to drive the enforcement point. The VPN example from the introduction is an example of these model.

ACM3 RBAC User to Role Mapping

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 name 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 control group with the role name defined at the target service. The policy of which subjects are mapped to application roles (permissions sets) can be attribute based or a simple access control list, or some combination of both.

Subject -> Role assignment in Grouper, - Permission -> Role at service

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

Figure 9: Access Control Model 3 - RBAC User to Role Mapping

For ACM3 to work well the target system needs a mechanism to associate the Grouper group with the role name configured in the applications RBAC system. This could be done with custom integration of the Grouper client or by making the group available in LDAP. The mapping between Grouper group and application role name is what enables the User -> Role mapping to stay in sync with policy.

ACM4 WebSSO Short-circuit

Often for pragmatic reasons one wants to limit access to a target service by locating the policy enforcement point at the web single sign-on layer. Two 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, and 2) when the target service lacks a good unauthorized user experience. In the first case, inserting a PEP within the authentication flow enables Grouper to overlay policy control. In the second case the user experience can be improved by redirecting the user to a more helpful “unauthorized” page rather than receiving a cryptic error page from the target service.

PAP, PDP done in Grouper, PEP at WebSSO

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

Figure 10: Access Control Model 4 - WebSSO Short-circuit

It should be noted that ACM4 does not absolve the application from also having to do some form of access control.

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.

ACM: Coarse-grained 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.

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.

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

grouperGdgAcmAffiliation