Groups Authorization Manager#

Introduction#

The Groups authorization manager provides coarse-grained CRUD (Create, Read, Update, Delete) access control to resources, based on group membership and access token claims. Because the Groups authorization manager is resource-agnostic, it supports all types of resources, including both the System for Cross-domain Identity Management (SCIM) APIs and the GraphQL APIs.

Usage and Configuration#

The Groups Authorization Manager works by requiring an optional set of scopes and a group to allow access. If one or more scopes are configured then any request being authorized needs to contain all scopes in that list. This is checked independently from what type of operation is performed. Once the scopes have been authorized, the groups claim or the urn:se:curity:claims:admin:groups claim is evaluated to determine what groups the requesting user belongs to. These are matched against the rule-list of groups to determine if the group has access, and what type of access should be granted.

Group Rules#

The group rules are configured as a list, where each list item contains:

• A required group name. A special case is allowed which is the * group, which matches any group.
• A set of allowed CRUD operations.

The overall allowed CRUD operations is the union of the allowed CRUD operations for each rule matching a user group.

Example#

Consider a Groups authorization manager configured with the following three rules:

• A user belonging to only the user group will only be able to read.
• A user belonging to only the creator group will only be able to create.
• A user belonging to both the user and creator groups will be able to read and create.
• A user belonging to admin group will be able to do all four types of CRUD operations.

Mapping between CRUD operations and resource operations#

The mapping between CRUD operations and resource (GraphQL and SCIM) operations is described in authorization manager rules .