Group projection

Both styles carry group membership: the header above, and for a relying party that asks for the groups scope, the groups and group_ids claims in the id_token, the access token and the userinfo response. By default all of them carry every group the person belongs to. That is more than most applications want and more than most should have: an internal wiki learns that somebody is in hr-investigations, and the payload grows with the size of the directory rather than with the needs of the application.

An application can be told only what concerns it:

cardinal group create grafana-admins -app grafana  # a group that belongs to it
cardinal app groups mode grafana owned             # tell it those, and no more
cardinal app groups allow grafana staff-apps       # plus one it does not own
cardinal app groups show grafana                   # what it is told, and why

The same is on the application's page in the console.

A system group is never projected. Membership of directory-admins is authority inside Cardinal, and an application branching on it would be reading a Cardinal internal as though it were one of its own roles.

This changes what an application is told, never what Cardinal decides. Policy is evaluated against the full membership either way, so narrowing a projection can neither refuse anybody nor admit anybody. If an application stops recognising somebody after a projection is narrowed, the fix is to allow the group, not to widen a policy rule (ADR 0032).

Every application starts telling everything, including newly registered ones, so nothing changes until somebody narrows it deliberately.

In the console

An application's page under Integrations → Applications shows the mode, the groups it is told about and whether each is owned or explicitly allowed, and the total number of groups in the directory, because "told about every group" is a setting, while "told about 14 groups, 12 of which it does not own" is an argument.