Groups

A group is an entity like any other, and the thing policy reads.

cardinal group create engineers -display "Engineering"
cardinal grant engineers alonfils
cardinal members engineers
cardinal memberships alonfils

Groups can contain groups

Membership is resolved with a recursive query, so a group inside a group works and policy sees the transitive closure:

$ cardinal memberships alonfils
alonfils belongs to, at now
  doc-inner                direct
  engineers                direct
  doc-outer                inherited, depth 2

The depth is printed because "why does this person have that" is usually answered by a group they were never directly added to.

Groups that belong to an application

A group can name an application as its owner:

cardinal group create grafana-admins -app grafana

That matters for what the application is told about people. An application in owned mode is told about the groups it owns and nothing else. See group projection.

System groups

Three groups confer authority inside Cardinal, and they are marked system: directory-admins, user-admins and security-admins. What each may do is administration tiers.

Two rules follow from being a system group, and both are enforced rather than documented:

• A system group is never projected to an application. An application branching on directory-admins would be treating a Cardinal internal as one of its own roles.
• A system group is never provisionable over SCIM, so an upstream identity provider cannot make anybody a Cardinal administrator.

In the console

Directory → Groups lists them, and a group's page shows its members and the grant that put each of them there. Granting is a form with three fields (group, expires, reason), the same three the CLI takes as flags.