What is federated identity?¶
Federated identity is a trust arrangement in which one system accepts identity information issued by another. The receiving application does not need to check the user's original password; it validates a signed assertion or token and uses its claims to decide which local identity receives access.
What crosses the boundary is a statement, not a password¶
Northstar configures Microsoft Entra as the identity provider for a cloud case application. Dave asks the application for access. Entra authenticates Northstar user object 4a86…91bd and issues a SAML assertion intended for that application. The assertion says, in effect, who issued it, which subject it concerns, which application may accept it and when authentication occurred.
The application validates the assertion, maps its NameID to local user caseuser-184 and creates a separate application session.
Federation links two identity namespaces. The join must be shown through preserved fields, not assumed from a familiar email address.
Read the assertion as a linking record¶
| Element | Plain meaning | Why preserve it? |
|---|---|---|
| Issuer | The identity system making the statement | Identifies the trust source to compare with the authenticating tenant |
| Assertion or token ID | The identifier for this issued statement | Can distinguish transactions and support correlation where other records retain it |
Subject / NameID | The identity value being asserted | Provides the value the application may map to a local user |
| Audience | The application or service for which it was intended | Tests whether the statement was issued for the relevant relying service |
| Authentication instant | When the identity provider says authentication occurred | Separates the original check from later application activity |
| Claims or attributes | Statements such as identifier, name, email or group | Explain the values supplied to the application and possible mapping decisions |
A claim is a statement supplied by the issuer, not independent proof of its underlying truth. The application still decides whether to trust it and how to map it.
Configuration history can change the meaning¶
Northstar may later rename Dave, change the NameID format, replace the signing certificate or move the application to another tenant. A present-day test sign-in may therefore differ from the event under investigation.
Preserve the historical trust configuration, issuer and application identifiers, signing-certificate details, mapping rules and relevant change events. Compare them with the identity-provider sign-in and the application's local audit record. This can establish which configuration connected the two identities at the relevant time.
Microsoft SAML fields - checked 2 September 2026
Microsoft documents SAML assertions containing an assertion ID, issue instant, issuer, subject/name identifier, conditions including audience, authentication statement and attributes. Its Entra claim configuration can use a user principal name or another configured value for NameID and can send application-specific claims.
These are Microsoft Entra examples, not universal field promises for every provider or protocol. OpenID Connect uses different token structures, and application logging varies.
Federation and SSO answer different questions¶
Single sign-on describes the user's ability to reach several applications through a central sign-in. Federation explains the technical trust that can allow one system's identity statement to be accepted by another. Federation can support SSO, but the terms should not be treated as synonyms.
Entra recorded authentication for Northstar user object
4a86…91bd. Under the then-current trust, it issued an assertion for the case application, which mapped the assertedNameIDtocaseuser-184. The application then recorded activity in that local session. Device and surrounding evidence remain necessary to attribute the activity to Dave personally.
The point to remember
Federation creates a testable bridge between identity systems. Preserve the issuer, subject, audience, time and mapping, then connect the assertion to both the original authentication and the local application event.
