What Is Federated Identity?

Federated identity lets one organisation accept authentication performed by another. A user signs in with their own organisation's identity provider and is admitted to a service operated by someone else, without that service ever holding their credentials.

It is the mechanism behind business-to-business access, most cloud application sign-in, and any arrangement where partners or customers reach your systems using their own accounts.

Trust is the whole mechanism

The relying party accepts an assertion from the identity provider because it has been configured to trust it. Everything rests on that configuration: which providers are trusted, which signing keys are accepted, and which claims are believed.

That makes the trust configuration one of the most sensitive settings in the estate. Adding a trusted provider, or accepting a new signing certificate, is functionally equivalent to granting the ability to authenticate as your users — and it is often a configuration change nobody monitors.

Where federation goes wrong

Unmonitored trust changes, as above. Assertions accepted without validating the signature, audience or expiry — all of which have appeared as real vulnerabilities in real implementations. Guest and partner identities granted access and never reviewed, because they belong to somebody else's joiner-mover-leaver process.

That last one is the routine operational failure. When a partner's employee leaves, their access to your systems ends only if their own organisation disables the account — which you cannot see and cannot verify.

Attribute mapping is a security decision

Federation carries claims as well as identity — group membership, department, role — and applications frequently make authorisation decisions from them. That means the identity provider is effectively deciding authorisation at the relying party.

Where the provider is another organisation, you are accepting their group management as an input to your access control. A partner who adds someone to a group grants them access to your systems, without any action on your side.

The safer pattern is to use federated claims for identity and make authorisation decisions locally, mapping external identities to roles you control. It is more work and it keeps the access decision where the consequences land.

Trust changes deserve alerting

Adding a federated identity provider, modifying a trust relationship or registering a new signing certificate are high-consequence changes that look like routine configuration in an audit log.

Attackers who reach identity infrastructure have used exactly these changes to establish persistent, legitimate-looking access — authenticating as any user, through a provider they control, with no malware and no credential theft.

These belong on a short list of changes that generate an alert to a human rather than a log entry someone might review, and the list is short enough that the alerting is not noisy.

The thing most worth getting right

Where to start

List the external identities with access to your systems and when each was last reviewed. In most organisations the list is longer than expected and the review date is blank.

See identity governance for contractors. GuardsArm runs security risk assessments.