Identity and SSO permission mappings

Platform administrators map verified values from a customer’s identity provider to roles in NomOS.

What is matched

A mapping compares one exact, case-sensitive value from the configured groups or roles claim. Both claims must be string lists; scalar or unknown values do nothing.

Mappings are issuer-bound. A value from another identity provider cannot activate the mapping.

Available targets

The target type limits the roles that can be selected:

Room roles

member or room_owner in one selected room.

Platform roles

tenant_admin or auditor at platform scope.

Functional cross-room roles

architecture, security or business for read-only decision access across rooms.

Sign-in and reconciliation

A new mapping creates no access by itself. It takes effect the next time an affected person with the mapped value signs in or renews their token.

With authoritative reconciliation, an absent value removes that mapping’s grant at the next sign-in or token renewal. Additive mappings retain the last confirmed grant.

Change and delete

Changing the identity, value, target, or role of a mapping, or deleting it, revokes its current grants immediately. A changed mapping grants access again only after the next sign-in or token renewal.

Access justified by another mapping remains. Manual memberships and manually assigned functional roles always win and are never changed by claim reconciliation.

Evidence and origin

Every effective change to a mapping and every effective reconciliation at sign-in creates an evidence record. The grant counter shows how many identities are currently justified by each mapping.