Access Control Models

Overview

grouperGdgAcmHighLevel

The Grouper approach to access management 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, provisioned via Grouper. The user might then have access to projects due to configured access in the Confluence admin screens. (This is the "Policy groups and dynamic application permissions" model explained below). 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.

This section use terminology and models from NIST SP 800-162 and XACML to demonstrate a variety of models leveraging the overall approach. Note, you could use multiple models at once, or could engineer hybrid approaches.

Most of the Access Control Models (ACM) 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 most common ACMs are listed here, with a diagram and more details below on each one.

Access Control Model	Type(s)	Description	When to use	Notes
Policy groups and static application permissions	Policy groups	Roles are managed in Grouper and the permissions of those roles are hard-coded in the application or are opaque. 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 dynamic application permissions	Policy groups	Very similar from a Grouper perspective to "Policy groups and static application permissions". Authorization configuration is in two places, who has which role (in Grouper), and what each role/user can do (in app)	If the application can configure permissions based on users/roles, and roles can be provisioned from Grouper	Two users in the same role might have different permissions if there are individual permission assignments in addition to role permissions assignments
Policy group for coarse-grained access	Policy group Coarse grained authn	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 application, or even if you can!	This can be setup as a reverse proxy to protect the application from any unauthenticated, unauthorized access
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
Grouper managed permissions	Policy groups Externalized permissions	Policy groups are used as roles in Grouper and permissions are assigned 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. Its possible though less common for packages as well.	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 permission screens are usable for the application
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 Use only as a last resort You could work around this it might not be ideal Lacking delegation

The following sections provide a diagram and more detail on each of the ACMs listed in the table above.

ACM Policy groups and static application permissions

Like many ACMs that use policy groups, access policy administration and the policy decision point (pre-computed 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. Grouper policy groups support audit, compliance, and attestation.

Access policy groups configured in Grouper based on institutional meaningful cohorts (i.e. reference groups, ad hoc groups, etc)
Authorization provisioned to application e.g. with LDAP, SAML, WS, direct provisioning, etc
Application uses those role(s) with hard-coded or static permissions to allow the user to perform actions

grouperGdgAcmPolicyStaticPermissions

ACM Policy groups and dynamic application 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. It's possible there are permissions assigned to individual users in the application (not necessary for this ACM). For this reason, Grouper's view of what a user has is not necessarily 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 access the user has, but you need to consult the application for the full picture. (The Confluence example mentioned

Access policy groups configured in Grouper based on institutional meaningful cohorts (i.e. reference groups, ad hoc groups, etc) provides User -> Role mapping
Authorization provisioned to application e.g. with LDAP, SAML, WS, direct provisioning, etc
Fine-grained permission sets are managed at the target service (Role -> Permissions and User → Permissions)

grouperGdgAcmPolicyDynamicPermissions

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 enables defense-in-depth by providing an outer perimeter or "front door") 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 (e.g. identify the admin users). So at a minimum the policy group could be an affiliation (e.g. "employee" at the institution), even if only certain employees have roles in the application. Note, you would not literally use a ref group, you would have a policy group that contains that ref group so you can manage exceptions. The most precise coarse-grained policy group would contain the union of all roles in the application.

There are several options for the policy enforcement point (PEP) (i.e. "front door") to restrict access

PEP	Description	When to user	Notes
IdP	The Shibboleth IdP can block access or send a blank assertion if the authenticated user is not in a certain Grouper policy group when authenticating to a certain Service Provider (SP)	SaaS services Any SP integrated with your IdP	There might or might not be a friendly error page Some IdP operators might not to mix authn with authz Some SaaS apps might allow SAML authn in addition to local authn, so it might not provide the sufficient intended protection in those cases (e.g. box) You could mine splunk logs to see what the population has recently used an app to make sure you are not making this group too restrictive
Load balancer (e.g. F5)	Application load balancers that reverse proxy traffic might be able to limit traffic by group. For example the F5 load balancer has been successfully integrated with SAML and can restrict traffic to an application by entitlement from Grouper	Any application behind a load balancer	The application needs to be reverse proxiable The UI (SAML) traffic needs to be separate from any WS or public traffic Blocking all network traffic by a reverse proxy improves the threat model since attackers must be authenticated and authorized Instead of a load balancer, the component could be an application firewall
Web server (e.g. Apache)	Web servers can reverse proxy traffic or just serve pages and can block all network traffic unless someone is authenticated and authorized	Any application reverse proxied behind an apache Any apache application	The application needs to be reverse proxiable if using apache as reverse proxy The UI (SAML) traffic needs to be separate from WS or public traffic Blocking all network traffic by a reverse proxy improves the threat model since attackers must be authenticated and authorized
Service provider (SP)	The SP can block authentications if not in a certain Grouper group	Any application that uses an SP	It's possible that nefarious traffic could attack the application since the SP is generally along side the application and not in front
"Can login" role	The application might have a group that indicates a user has access (e.g. jira-users)	If the application has a "can login" group	The provisioned list of accounts, or a role of "can login" or "user" is similar to a coarse-grained security control This does not help secure network traffic like a reverse proxy

A coarse-grained access policy group configured in Grouper based on institutional meaningful cohorts (i.e. reference groups, ad hoc groups, etc) indicated who can use an app
Authorization provisioned (e.g. LDAP, SAML, etc) to the enforcement point (e.g. IdP, F5, Apache)
If a user is not authorized they should be directed to the "not allowed for this app" page
The application should do its own security using another ACM (e.g. get roles from other Grouper policy groups)

grouperGdgAcmPolicyCoarseGrained

ACM: Grouper for access reporting

It is ideal if Grouper can be system of record for authorization for an app. 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 from 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. It could also be loaded near real-time

Grouper loader via SQL or LDAP (preferred)
1. You could ETL the data to a SQL or LDAP first
Web services
Custom job
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 unnecessary authorizations.

Authorizations are managed in the application
Authorizations are loaded into Grouper
Deprovision, attest, and report in Grouper by making security changes in the app

grouperGdgAcmReporting

ACM: Grouper managed permissions

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.

Create policy groups similar to other ACMs
Convert those groups into roles
Configure permission resources and assign to roles / users (in Grouper)
Provision roles/permissions to application. Note, something more complex than LDAP/SAML is generally used, e.g. WS or SQL

grouperGdgAcmPermissions

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 eduPersonAffiliation: 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 more common years ago before sophisticated authorization was common. 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.

It's 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
Affiliations provisioned (e.g. LDAP, SAML, etc) to the application
The service allows access or uses the affiliation to map to a role / permission set

grouperGdgAcmAffiliation