Federation · Authorization · 4 min read
Federation and Entitlement Management: How They Fit Together
Short answer
Federation moves identity and a few attributes from an identity provider to an application at sign-in; entitlement management keeps track of the permissions each identity holds and enforces them, either inside the app, through provisioning, or with an external policy engine.
Key takeaways
- Federation answers who the user is and how they signed in; it is a poor channel for detailed permissions.
- Coarse roles or groups can travel in a SAML assertion or ID token; fine-grained rights belong in a policy or entitlement system.
- SCIM provisioning and access reviews keep entitlements accurate after the user has signed in for the first time.
Identity projects often start with single sign-on and stall at the next question: once the user is in, what are they allowed to do? Federation and entitlement management are separate disciplines that meet at that point, and mixing them up leads to bloated assertions or apps that grant too much.
What does federation actually deliver?
Federation delivers a trusted statement, at sign-in time, that this user was authenticated by a particular identity provider, plus a small set of attributes.
With SAML 2.0 the statement is an XML assertion; with OpenID Connect it is an ID token, a signed JWT. Either way the application learns a stable identifier (NameID or sub), maybe an email address, a display name and some group memberships. It learns how and when the user signed in. It does not learn much else, and it learns it once per session.
That is exactly right for authentication. It is a weak foundation for authorization, because permissions change during a session, differ per resource and are often more numerous than any assertion should carry.
What is an entitlement?
An entitlement is one specific permission granted to an identity: a role, a group, a license, an approval limit, access to one record set.
Entitlement management covers the life of those permissions:
- Granting them through requests, approvals or rules based on job attributes.
- Recording them in a directory, the target application or a central store.
- Enforcing them when a request arrives.
- Reviewing and removing them, so a person who changed teams does not keep their old access.
Products in this space range from identity governance platforms that run access reviews to runtime authorization engines that evaluate XACML or other policy languages. Our entitlement management overview compares the categories.
Where should permissions live?
Coarse grants can travel with the identity; fine-grained decisions should be made close to the resource, at request time.
A practical split:
| Kind of permission | Example | Best channel |
|---|---|---|
| App access | "May use the CRM" | Federation policy at the IdP |
| Coarse role | "Sales manager" | Group or role claim in the assertion or token |
| Account and license | "Has a Pro seat" | SCIM provisioning to the app |
| Fine-grained rule | "May approve invoices under 10,000 in region EU" | Policy engine (ABAC/XACML) or app logic |
| Time-bound grant | "Admin for the next 2 hours" | Privileged access tooling, short-lived tokens |
The common mistake is to push every rule into claims. Assertions grow to many kilobytes, some browsers and proxies choke on big POST bodies or headers, and every connected application sees your whole internal permission model.
How do the standards connect?
SAML or OIDC carries identity, SCIM keeps accounts and groups in sync, and XACML or a similar policy model handles detailed decisions.
Picture a user joining the finance team. HR updates the record. The governance system grants the "finance-analyst" role and SCIM pushes the account and group to the expense application. When the user signs in, the IdP sends a SAML assertion with the group. When they try to approve an expense, the application asks a policy decision point whether a finance analyst in Sweden may approve this amount for this cost center. Each step uses the standard designed for it.
The authorization guide goes deeper into RBAC, ABAC and the XACML architecture, and the provisioning guide covers SCIM.
How can I see what my IdP is sending?
Decode a test assertion and read the attribute statement.
Many entitlement problems turn out to be attribute problems: the group claim is missing, uses a different name than the app expects, or includes far too many values. Capture a SAMLResponse from a test sign-in with your browser's developer tools and paste it into the SAML Decoder. The attributes table shows exactly what the application receives.
Questions
Can I send all of a user's permissions in the SAML assertion?
You can send groups or roles, and many SaaS apps expect exactly that. Sending hundreds of fine-grained rights makes assertions large, leaks your internal model to every application, and leaves permissions stale until the next sign-in.
Is entitlement management the same as identity governance?
They overlap. Identity governance and administration (IGA) products manage who should have which entitlements, run access reviews and certify them. Runtime authorization products evaluate policies when a request happens. Many organizations need both.
Sources
Tagged: Federation, XACML, SAML, Identity, Authorization, IAM