Access Control Models

Overview

The overall approach to access management with Grouper is to create and maintain institutional meaningful cohorts (reference groups), which in turn are used to drive access policy groups#accessgroup. The access policy groups then provide subject attributes (role names or entitlements) that are mapped to coarse or fine-grained permission sets at the target service.

How the fine-grained application permission sets are managed is usually specific and local to the target service. In some cases, the privilege to use a particular service (a set of rights to specific resources) can be mapped to a subject attribute representing an entitlement (i.e. subject is entitled/authorized to access the service). In these cases, a membership assignment in an access policy group can drive an eduPersonEntitlement value that is often consumed by the target service via a SAML assertion. In other cases, group membership must be provisioned to the target service to effectively control access.

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.

ACM1 Grouper Subject Attributes

In this model, Grouper is used to master subject attributes that represent some type of affiliation or status at the institution. 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. The subject attribute policy is a group configured in Grouper and built up with reference groups similar to an access policy group, but with no particular service in mind.

PAP, PDP, and PEP are all at the target service:

1. A subject attribute like eduPersonAffiliation is mastered in Grouper and reflected into an LDAP based enterprise directory.
2. The subject attribute is either passed to the target service via SAML or queried via LDAP after authentication.
3. PAP: Access control policy is configured at the target service
4. PDP, PEP: Policy decision point and the policy enforcement point are all done at the target service

Figure 7: Access Control Model 1 - Grouper Subject Attributes

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. If you need service specific policy, consider using access policy groups and the access control model described in ACM2 Grouper as PAP and PDP.

xxx add additional considerations/warnings from gte example xxx

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

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: 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

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

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

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. 

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.

Distributed Access Control Management

All the models described above 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. The general pattern is to include reference groups whose management has been delegated to the appropriate parties. This can take the form of application specific reference groups, organizational reference groups, or identity lifecycle and security groups. Just as with institutional reference groups, membership changes in the delegated groups are immediately reflected in access policy.

Application Permissions Management - RBAC with Grouper

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. In all cases the target system itself is responsible for its own permission management.

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. From an application architecture perspective, Grouper becomes a subsystem of the overall application. Grouper fulfills all application permission management needs, and can be integrated with the access control models previously discussed.

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