Note: there are 4 levels of hierarchies in Grouper permissions.
- Indirect group membership to have a role
- Permissions that imply other permissions (so you can assign one permissions and get a lot of rights)
- Actions that imply other actions (e.g. admin implies all other actions)
- Role inheritance so a role can inherit all permissions from another role, and add some more
Here are examples and diagrams of Grouper permissions
When to use Grouper Permissions
- When the application can support permissions being provisioned to it
- Helps if your application has a specific and probably custom UI to assign permissions
- E.g. imagine assigning permissions on Confluence pages outside of the Confluence app? Might be difficult to use
- Grouper has a permissions UI but it is generic
- Grouper permissions do not provision with PSPNG. You need to provision permissions to the application using Grouper WS or SQL or Java
- Grouper permissions will tell you real time when assignments change (for real time provisioning), but it only indicates that a role has changed somehow
- If you are doing a change log consumer or messaging, you need to get that indication and do a full sync of permissions for that role
Role and Permission Management as of v2.0 and above
- Grouper permission limits
- Grouper permissions allow and disallow
- Grouper permissions example
- Grouper resource or permission picker
Grouper has the capability to manage external applications' roles and permissions, and can function as a central permission management system.
Note that "privilege" is interchangeable with "permission", but Grouper already has documents about internal Grouper privileges on Groups / folders / etc. so the word "permission" is used here.
- Roles can be stored in Grouper. Roles can be assigned to subjects or groups.
- External application permission objects can be stored in Grouper.
- Permissions can be assigned to roles or to subjects since they are modeled as types of attributes on role memberships or roles.
- Roles can be configured to imply other roles. For example a Senior Loan Administrator is a Loan Administrator, plus a few more security grants. Roles can be connected like a directed graph of role inheritance
- Permissions can grouped into permissionSets. E.g. if an organization hierarchy was represented as permissions, then the higher level organizations can imply the lower level ones. Note this does not have to be a hierarchy
- Permission assignments have an optional "action" qualifier. This is a free form string which is configured per permission definition. E.g. a user can READ certain orgs, and WRITE certain other orgs.
- Permission actions can imply other actions. e.g. Having ADMIN on a permission resource implies being able to READ or WRITE it. Note, there are no built in actions (though a default "assign" exists if none specified). So the actions and action inheritance needs to be defined
- Permission assignments can be ALLOWED or DISALLOWED. With all the inheritance (permission resource, role, action, memberships), if a permission is allowed to a wide population, then it can be narrowed with a disallow. For example, someone could be assigned to READ all orgs in the University in the payroll system, except for the user's own org.
- Permission limits can be assigned to direct permission assignments. The limit can have a value or type string, numeric, date, etc. The limit has logic associated with it to use the optional value and context from the caller to decide if the permission is allowed or not. There are built-in limits for value (e.g. allowed to approve if value less then 50000), time of day (only allowed during business hours), ip address, etc.
- All permissions operations are exposed through the Grouper Lite UI
- Demo of permissions
- Attribute definitions (definition holds security, name, actions for all permission names associated)
- Attribute definition privileges (attribute definition privileges control who can list the permissions, or assign them)
- Permission name hierarchies
- Role editor
- Directed graph visualization
- Permissions demos of allow/deny
- Common setup
- Role assignment vs individual assignment
- Role assignment vs individual assignment up the hierarchy
- Role assignment vs individual assignment up the hierarchy2
- Action directed graph priority
- Various role assignments
- Role inheritance
- Directed graph priority
- Directed graph priority with tie
- Resource directed graph tie with different actions
- Permission limits UI
See also the Overview of Access Management Features page for guidelines of when to use rules, roles, permission limits, and enabled / disabled dates.
Create a role
Add a member to a role (in this case a group)
Create a permission definition
Add one permissions resource name to another (permissionSet)
Assign a permission to a role
Assign a permission to a member in a role
Get the permission assignments (not necessarily active or allowed), assigned to a role, immediate, based on role name, print these out
Get the permission assignments (not necessarily active or allowed), assigned to a role, immediate, based on permission name, print these out
The view for permissions is grouper_perms_all_v. Note, results here need to be processed is allow/disallow is used, also you should take into account if the records are active or not
get all attributes assigned to a role, assuming direct assignment (unassignable)
get all roles that are assigned a given attribute, assuming direct assignment (unassignable)