A user signs in to an identity provider.
They select an AWS account.
A browser redirects them.
A few moments later, they are inside the cloud console without entering another password.
The experience looks like credential convenience:
sign in once
access another system
Behind that convenience is a more important decision.
AWS has agreed to accept identity claims from another authority.
The identity provider may assert:
This user is Mariam.
She belongs to the PlatformEngineering group.
Her authentication included
recent multi-factor verification.
AWS does not need to manage Mariam’s original password.
It needs to decide whether it trusts the issuer, which claims it accepts and what local authority should follow.
Single sign-on is the user experience.
Federation is the trust relationship behind it.
Federation is mostly about deciding who is allowed to assert identity, which assertions will be accepted and what authority those assertions may unlock.
Protocols, certificates and tokens carry a trust decision that must be designed first.
Federation is a trust pipeline
Without federation, every system may maintain its own users and credentials.
AWS account:
local user
Azure tenant:
local user
GCP organisation:
local user
internal platform:
local user
The same person accumulates:
- several passwords
- several multi-factor registrations
- several account lifecycles
- several access reviews
Federation separates identity proof from resource authority.
The identity provider answers:
Who is this person or workload,
and how was it authenticated?
The relying system answers:
What may that identity do here?
The complete path is:
RECEIVE ASSERTION
│
▼
VERIFY ISSUER AND ASSERTION
│
▼
IDENTIFY SUBJECT
│
▼
EVALUATE CLAIM PROVENANCE
│
▼
MAP TO LOCAL AUTHORITY
│
▼
ISSUE BOUNDED SESSION
│
▼
AUDIT, EXPIRE OR REVOKE
The external issuer establishes identity.
The receiving system retains control over local permissions.
Trusting an identity assertion should not require surrendering authorisation decisions.
Assertions have scope and provenance
An assertion may describe a human:
subject:
user-7f24a1
groups:
platform-engineering
authentication method:
multi-factor
or a workload:
repository:
mantrobuslawal/bfstore-infrastructure
workflow:
deploy-production
environment:
production
The issuer is saying that these statements about the subject are true.
The relying system must verify the assertion, identify the subject, decide which claims have trustworthy provenance and determine which local authority they may unlock.
Federation does not make claims true by magic. It creates a structured way for one system to vouch for them.
Trust belongs to a specific issuer
A valid signature is not enough. The receiving system also needs to know who signed the assertion.
TOKEN
│
▼
SIGNATURE VALID
│
▼
ISSUER TRUSTED?
A valid token from an untrusted issuer should still be rejected.
For example, bfstore may trust https://identity.bfstore.example but reject an equivalent-looking assertion from another issuer.
The cryptography proves that a particular issuer produced the assertion.
Policy decides whether that issuer is authorised to make relevant claims.
AUTHENTIC
really produced by the issuer
AUTHORISED
issuer is allowed to make
this claim for this purpose
Audience limits where an assertion belongs
A token may be intended for one receiving system.
The audience claim identifies that destination.
issuer:
identity.bfstore.example
audience:
aws-workforce-access
A token intended for an internal documentation service should not automatically work against the cloud control plane.
Audience checking limits where an assertion is intended to be accepted.
It is one part of preventing cross-service reuse, alongside expiry, recipient checks and flow-specific replay protection.
TOKEN FOR SERVICE A
│
╳
│
SERVICE B
Without audience validation, one valid assertion may be accepted by systems for which it was never intended.
Identity is issuer plus subject
The subject claim identifies the user or workload represented by the assertion.
A human subject might be:
user-7f24a1
A workload subject might be:
repo:mantrobuslawal/bfstore-infrastructure:
environment:production
The relying system should treat the issuer and subject together as the federated identity.
FEDERATED IDENTITY
issuer + subject
The same subject string could legitimately appear beneath two different issuers and represent different identities.
The relying system should know whether the subject is unique, reusable or changeable, and whether the subject or a repository owner can influence it.
A display name is usually a weak primary identifier. Human-readable attributes help policy and audit, but stable identifiers are stronger trust anchors. For workloads, immutable repository, organisation or workflow identifiers can be safer than names alone.
Claims should not be trusted equally
An issuer may include many claims. The receiving system should use only those with suitable provenance.
A user-editable profile field, for example, should not be allowed to produce administrator access.
USER-EDITABLE CLAIM
group:
production-admin
For every policy-relevant claim, the relying system should know:
Who assigns it?
Who may change it?
How quickly do changes propagate?
Is it unique?
Is it verified?
Can the subject influence it directly?
Federation is only as strong as the governance behind the claims being trusted.
Authentication context may affect sensitive access
An identity provider may describe how the user authenticated.
For example:
authentication:
password
multi-factor:
true
A relying system may require stronger and more recent evidence for sensitive authority.
READ-ONLY DEVELOPMENT ACCESS
normal authenticated session
PRODUCTION ADMINISTRATION
recent multi-factor authentication
temporary elevation
managed device
The federation relationship still depends on trusting the issuer to report that context accurately.
A claim such as mfa=true matters only when the issuer’s authentication policy gives it a reliable meaning.
Local authority remains local
Suppose the identity provider asserts:
groups:
platform-engineering
AWS might map that group to a permission set:
PlatformEngineer
The permission set then grants access to selected accounts.
IDENTITY CLAIM
│
▼
GROUP MAPPING
│
▼
PERMISSION SET
│
▼
ACCOUNT ASSIGNMENT
│
▼
TEMPORARY CLOUD ROLE
The identity provider does not define every cloud permission. AWS still controls the permission set, its policies, account assignments and session duration.
The external claim contributes to a local authorisation decision. The relying system remains responsible for the final authority.
Group mapping can create hidden privilege
Group-based federation is convenient.
It can also hide powerful access behind one directory change.
Suppose this group:
bfstore-production-admins
maps to administrator access across production.
Adding a user to that group may become the effective privileged-access decision.
DIRECTORY GROUP CHANGE
│
▼
FEDERATED CLAIM
│
▼
PRODUCTION AUTHORITY
The governance system must protect group ownership, membership changes, approval, audit, review and removal.
A carefully designed cloud role does not remain carefully controlled when anyone can casually alter the upstream group that activates it.
The privilege boundary may begin outside the cloud account.
Provisioning and federation solve different problems
Federation allows a relying system to accept identity assertions.
Provisioning creates or updates identity records, groups and assignments in that system.
FEDERATION
user signs in through
an external identity
PROVISIONING
user, group or assignment
is created or updated
Some systems accept federated users directly. Others require local users, groups or assignments before access succeeds.
A sign-in may fail because:
- the assertion is invalid
- the local assignment is missing
- the user was not provisioned
- group synchronisation is stale
Treating all four as “SSO is broken” makes diagnosis rather foggy.
Deprovisioning and session duration bound authority
Suppose a person leaves the organisation.
The identity provider disables their account.
The relying systems should stop accepting new sessions.
Existing sessions may remain active until they expire or are explicitly revoked.
USER DISABLED
│
▼
NEW AUTHENTICATION BLOCKED
│
▼
EXISTING SESSION?
│
├── revoked
└── valid until expiry
The practical removal time depends on token and session lifetime, caching, provisioning delay, group synchronisation and local emergency accounts.
Federation centralises part of the lifecycle. It does not guarantee immediate removal everywhere.
The organisation should test how long authority survives after upstream identity is withdrawn.
Short-lived sessions reduce this window.
IDENTITY ASSERTION
│
▼
TEMPORARY ROLE SESSION
│
▼
AUTOMATIC EXPIRY
Session duration should follow the risk.
A read-only investigation session may last longer than a production administrator session.
Workload federation moves trust into the delivery system
Federation is not limited to human single sign-on.
A CI workflow can receive cloud access without storing a permanent cloud key.
GITHUB ACTIONS
│
▼
OIDC TOKEN
│
▼
CLOUD TRUST POLICY
│
▼
TEMPORARY DEPLOYMENT ROLE
The issuer asserts claims about the workflow.
The cloud trust policy decides which subjects and contexts are accepted.
It might require:
repository:
mantrobuslawal/bfstore-infrastructure
environment:
production
workflow:
approved-deployment
The cloud then issues temporary credentials.
Again, the important question is:
Who may assert that this workload
is the approved production deployer?
The answer includes the issuer and the controls governing the repository, workflow and environment.
Trust and permission policies constrain different sides
A weak trust policy might allow any workflow in the organisation to assume the production role. A compromised or newly created repository may then gain production authority.
A stronger policy requires the approved workload identity and context.
approved repository
approved workflow
production environment
expected issuer and audience
TRUST POLICY
who may become the role?
PERMISSION POLICY
what may the role do?
A narrow permission policy reduces what the role can do.
It does not justify allowing unnecessary identities to obtain that authority.
Both sides should be narrow.
Repository controls become identity controls
When a cloud trusts workload claims from a source-code platform, repository governance becomes part of cloud security.
If the cloud trusts an environment: production claim, repository controls become security controls. These include branch protection, workflow approval, environment reviewers, ownership and workflow modification permissions.
REPOSITORY CHANGE
│
▼
WORKFLOW IDENTITY CLAIM
│
▼
CLOUD ROLE ASSUMPTION
A developer who can modify the trusted workflow may be able to change what runs with cloud authority.
Federation moves the credential boundary.
It does not remove the need to secure the system controlling the federated identity.
Protocols carry the trust relationship
SAML and OpenID Connect use different formats and flows, but both carry the same architectural questions:
Who is the issuer?
How is the assertion signed?
Who is the subject?
Who is the audience?
How long is it valid?
Which claims are accepted?
How are claims mapped to authority?
The protocol affects token format, browser flow, discovery and key distribution. The trust design sits beneath those mechanics.
Selecting SAML or OIDC does not answer which groups should receive production access.
Protocol configuration transports the decision.
It does not make the decision wise.
Signing keys make the issuer believable
Assertions are normally signed.
The relying system verifies the signature using trusted public-key material.
ISSUER
signs assertion
│
▼
RELYING SYSTEM
verifies signature
This helps establish that the expected issuer created the assertion and that it was not altered after signing.
Key rotation still needs careful handling.
The relying system must learn new public keys before old keys disappear.
OLD KEY
still accepted during transition
NEW KEY
published and adopted
A failed rotation can block every federated login.
A compromised signing key can allow false assertions to appear legitimate.
Signing-key protection and rotation are therefore critical parts of the issuer’s operating model.
Metadata and discovery are trust configuration
Federation often relies on metadata describing the issuer, endpoints, keys and supported algorithms. Automated discovery reduces manual configuration but creates an availability and trust dependency on the retrieval path.
The architecture should know where metadata comes from, how changes are detected and what happens when retrieval fails.
Caching introduces a trade-off.
LONGER CACHE
better tolerance of discovery failure
slower adoption of emergency
trust changes
SHORTER CACHE
faster trust updates
greater dependency on
metadata availability
A login failure may be caused not by the user, but by the systems used to verify the issuer.
Federation is a high-blast-radius control plane
Central identity improves consistency.
It also creates a shared dependency.
AWS ───────┐
│
AZURE ─────┼──► IDENTITY PROVIDER
│
GCP ───────┤
│
PLATFORM ──┘
If the identity provider fails, new sessions may be unavailable across several systems.
Existing sessions may continue until expiry.
SHORT SESSION
smaller security window
greater dependency on
issuer availability
LONG SESSION
larger security window
less frequent reauthentication
The identity service needs availability design, monitoring, signing-key protection, emergency administration and tested recovery.
Federation centralises trust.
That trust centre must be operated accordingly.
Break-glass access remains outside ordinary federation
If the identity provider is unavailable, the organisation may still need to recover cloud systems.
A break-glass identity can provide a separate path.
FEDERATED ACCESS FAILED
│
▼
BREAK-GLASS IDENTITY
│
▼
RESTORE NORMAL IDENTITY SERVICE
The identity should be rarely used, strongly protected, separately monitored and tested periodically.
Its existence does not weaken the federation model.
It acknowledges that the federation service itself can fail.
The emergency path should be narrow enough that it does not become the favourite shortcut of an operator who finds single sign-on mildly inconvenient.
Federation should leave attributable evidence
A federated session should be traceable.
Useful evidence includes the issuer, subject, session, role, target account, authentication context, start time, expiry and actions performed.
The audit trail should allow an investigator to move from:
cloud API call
back to:
federated identity
For workload access, evidence should identify:
- repository or immutable repository identifier
- workflow
- revision
- environment
- assumed role
Federation improves central identity only when access remains attributable after it crosses into another system.
A session named merely:
federated-user
has successfully centralised ambiguity.
Trust changes need staged testing
Federation configuration can block access broadly.
A changed group mapping may remove production access.
An incorrect audience may reject every token.
An expired certificate may interrupt all logins.
A safe change process should test valid and invalid issuers, wrong audiences, expired assertions, unassigned groups and disabled users.
Changes should be validated in non-production environments before affecting critical access.
The emergency path should be confirmed before altering the primary trust relationship.
Identity infrastructure deserves the same staged delivery discipline as any other high-blast-radius control plane.
Two bfstore federation paths
The same trust pipeline can support people and workloads.
Human access
MARIAM
│
▼
EXTERNAL IDENTITY PROVIDER
│
│ signed assertion
▼
AWS IAM IDENTITY CENTER
│
▼
GROUP AND PERMISSION-SET MAPPING
│
▼
SELECTED AWS ACCOUNT
│
▼
TEMPORARY ROLE SESSION
The upstream identity provider owns authentication, multi-factor policy, account lifecycle and organisational groups.
AWS owns permission sets, account assignments, session duration and cloud audit records.
For example:
PlatformEngineers
mapped to
PlatformEngineer permission set
in
development
sandbox
shared services
Production access might require a separate group, recent strong authentication and temporary elevation.
The group name is not the permission.
It is an upstream claim that participates in a local authorisation decision.
A central identity provider could support AWS IAM Identity Center, Microsoft Entra ID for Azure access, Google Cloud IAM, Backstage and internal tools.
Each platform would still maintain its own native authorisation model.
Federation can centralise identity assertion without flattening every platform into one vague universal administrator role.
Workload access
A GitHub Actions workflow needs to deploy infrastructure into the development account.
The trust relationship might require:
issuer:
GitHub Actions OIDC
repository:
mantrobuslawal/bfstore-infrastructure
branch:
main
environment:
development
The resulting role may permit:
run approved infrastructure changes
inside
bfstore-dev
A separate production role would require a production environment claim, protected workflow, stronger review, narrower session and production-account scope.
DEVELOPMENT WORKFLOW
│
▼
DEVELOPMENT ROLE
PRODUCTION WORKFLOW
│
▼
PRODUCTION ROLE
The code may be shared.
The trust and authority remain separated by environment.
HUMAN IDENTITY CONTROL
directory, authentication
and group governance
WORKLOAD IDENTITY CONTROL
repository, workflow
and environment governance
Questions I now ask
Issuer
Which authority may
assert identity?
Subject
How is the identity represented
as issuer plus subject?
Claims
Which attributes have
trusted provenance?
Scope
Which audience and purpose
are allowed?
Mapping
How do claims become
local authority?
Duration
How long does authority survive
an upstream change or removal?
Availability
What happens when
the issuer is unavailable?
Audit
Can every action be traced
to the original subject?
These questions reveal the trust model more clearly than a diagram labelled simply SSO.
The mental model I am keeping
My earlier model was:
FEDERATION
use one login
to access several systems
The stronger model is:
IDENTITY SUBJECT
│
▼
IDENTITY PROVIDER
│
▼
SIGNED IDENTITY CLAIM
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
ISSUER AUDIENCE CLAIMS
│ │ │
└───────────────┼───────────────┘
▼
RELYING SYSTEM
│
▼
LOCAL AUTHORISATION
│
▼
TEMPORARY AUTHORITY
│
▼
AUDIT AND EXPIRY
The issuer and subject identify who or what is represented.
The audience limits where the assertion belongs.
Claim provenance determines which attributes may carry authority.
The relying system maps those accepted claims into local roles.
Session duration and revocation bound how long that authority survives.
Audit connects downstream activity to the original subject.
Break-glass access provides a recovery path when the trust system itself fails.
Federation is convenient because it reduces duplicated credentials and centralises identity lifecycle.
Its deeper value is that it makes a trust relationship explicit.
One system is permitted to assert identity.
Another system decides which assertions are acceptable and translates them into local authority.
That relationship should remain narrow.
A trusted issuer should not automatically make every claim trustworthy.
A valid identity should not automatically receive every role.
A group membership should not silently become permanent administration.
Federation works when the relying system knows exactly who may assert identity, which claims carry authority and where that authority must stop.
The sign-in button is the visible part.
The real architecture lives in the trust policy behind it.