Single Sign-On and Federation
Single sign-on (SSO) is an authentication architecture that allows users to authenticate once and access multiple applications without re-entering credentials. Federation extends this model across organisational boundaries, enabling users from one organisation to access resources in another through established trust relationships. Together, these capabilities reduce credential fatigue, centralise authentication policy enforcement, and enable secure collaboration between organisations that operate independently.
The security model differs fundamentally from per-application authentication. When each application maintains its own credential store, compromise of any single application exposes credentials that users have reused elsewhere. SSO inverts this risk profile: authentication occurs at a single, hardened identity provider, and applications receive cryptographic assertions rather than credentials. The attack surface concentrates at the identity provider, which can then receive proportionate security investment.
- Identity Provider (IdP)
- The authoritative system that authenticates users and issues assertions about their identity to other systems. The IdP maintains user credentials, enforces authentication policy including multi-factor requirements, and generates security tokens.
- Service Provider (SP)
- An application or service that relies on an identity provider for authentication. The SP accepts assertions from trusted IdPs rather than managing credentials directly. Also called a relying party (RP) in OIDC terminology.
- Assertion
- A cryptographically signed statement from an IdP declaring that a user has authenticated. The assertion contains the user’s identity and attributes (claims) relevant to authorisation decisions.
- Federation
- A trust arrangement between organisations that allows users authenticated by one organisation’s IdP to access another organisation’s resources without creating accounts in the second organisation.
- Trust Relationship
- A configured connection between an IdP and SP (or between two IdPs) that specifies cryptographic keys, assertion formats, and attribute mappings. Trust is unidirectional: the SP trusts the IdP, but the IdP need not trust the SP.
- Claims
- Individual pieces of information about a user contained within an assertion, such as email address, group memberships, or job title. Claims enable authorisation decisions without querying the IdP for each access request.
Authentication Flow Architecture
SSO authentication follows a redirection pattern where the user’s browser mediates communication between the service provider and identity provider. The user never enters credentials at the service provider; instead, the SP redirects unauthenticated users to the IdP, which performs authentication and returns a signed assertion.
+------------------------------------------------------------------+| SSO AUTHENTICATION FLOW |+------------------------------------------------------------------+
User Service Provider Identity Provider | | | |----(1) Access app----->| | | | | | |---(2) No session, | | | generate AuthnReq | | | | |<---(3) Redirect--------| | | to IdP | | | | | |----(4) AuthnRequest----|-------------------------->| | (via browser) | | | | | | | (5) Check for| | | IdP session | | | |<---(6) Login form----------------------------------| | (if no session) | | | | | |----(7) Credentials-----|-------------------------->| | | | | | (8) Validate | | | credentials | | | | | (9) Create | | | IdP session | | | | | (10) Generate | | | assertion | | | |<--(11) Redirect--------|---------------------------| | with assertion | | | | | |---(12) POST assertion->| | | (via browser) | | | | | | |--(13) Validate | | | assertion sig | | | | | |--(14) Extract claims, | | | create SP session | | | | |<--(15) Application-----| | | response | | | | |Figure 1: SSO authentication flow showing browser redirection pattern
The flow operates through browser redirects rather than direct server-to-server communication. This design enables SSO without requiring network connectivity between the SP and IdP, which matters for organisations with applications deployed across network boundaries.
Step 5 determines whether the user experiences true single sign-on. If the user has an active session at the IdP from authenticating to a previous application, steps 6 and 7 are skipped entirely. The IdP generates an assertion based on the existing session, and the user accesses the new application without entering credentials. A user who authenticated at 09:00 to access email can access the grants management system at 10:30 without re-authenticating, provided both applications trust the same IdP and the session remains valid.
Session validity depends on IdP configuration. Sessions expire after a configured idle timeout (30 minutes is common) or absolute timeout (8 hours is common), after which the user must re-authenticate. The SP may impose additional session constraints independent of the IdP session, requiring re-authentication for sensitive operations regardless of IdP session state.
Protocol Mechanisms
Two protocols dominate SSO implementations: Security Assertion Markup Language (SAML) 2.0 and OpenID Connect (OIDC). Both accomplish the same goal through different mechanisms, and organisations routinely operate both protocols simultaneously to accommodate applications with different support.
SAML 2.0
SAML is an XML-based protocol developed in the early 2000s and widely adopted in enterprise environments. The protocol defines three roles: the principal (user), the identity provider, and the service provider. Communication occurs through the browser using HTTP redirect and POST bindings.
The assertion is an XML document containing authentication statements, attribute statements, and authorisation decision statements (rarely used). The assertion is signed using XML Digital Signatures, and optionally encrypted using XML Encryption. A typical SAML assertion spans 50 to 200 lines of XML, though most of this structure is envelope and signature data rather than user attributes.
+------------------------------------------------------------------+| SAML ASSERTION STRUCTURE |+------------------------------------------------------------------+| || <saml:Assertion> || | || +-- <saml:Issuer> || | Identity provider identifier || | || +-- <ds:Signature> || | XML digital signature over assertion || | | || | +-- <ds:SignedInfo> || | | Canonicalisation and digest || | | || | +-- <ds:SignatureValue> || | RSA/ECDSA signature bytes || | || +-- <saml:Subject> || | | || | +-- <saml:NameID> || | User identifier (email, persistent ID) || | || +-- <saml:Conditions> || | | || | +-- NotBefore / NotOnOrAfter || | | Assertion validity window (300 sec typical) || | | || | +-- <saml:AudienceRestriction> || | Intended SP (prevents assertion reuse) || | || +-- <saml:AuthnStatement> || | | || | +-- AuthnInstant || | | When authentication occurred || | | || | +-- <saml:AuthnContext> || | How user authenticated (password, MFA, etc) || | || +-- <saml:AttributeStatement> || | || +-- <saml:Attribute Name="email"> || | user@example.org || | || +-- <saml:Attribute Name="groups"> || finance-team, all-staff || |+------------------------------------------------------------------+Figure 2: SAML assertion structure showing key components
SAML’s complexity creates implementation challenges. XML signature validation is notoriously error-prone; vulnerabilities in signature verification have affected major SAML libraries. The protocol specification is extensive, running to hundreds of pages, and implementations vary in their interpretation of optional features. Organisations deploying SAML should use well-maintained libraries rather than implementing the protocol directly.
OpenID Connect
OpenID Connect (OIDC) builds on OAuth 2.0 to provide an authentication layer using JSON-based tokens rather than XML. The protocol emerged in 2014 as a simpler alternative to SAML for web and mobile applications.
OIDC uses three token types. The ID token is a JSON Web Token (JWT) containing user identity claims, analogous to the SAML assertion. The access token authorises API access to protected resources. The refresh token obtains new access tokens without re-authentication. The separation of identity (ID token) from authorisation (access token) provides flexibility that SAML’s monolithic assertion lacks.
+------------------------------------------------------------------+| OIDC TOKEN STRUCTURE |+------------------------------------------------------------------+
ID Token (JWT)+------------------------------------------------------------------+| HEADER (base64) | PAYLOAD (base64) | SIGNATURE ||--------------------------|----------------------|----------------|| { | { | || "alg": "RS256", | "iss": "https:// | RSASHA256( || "typ": "JWT", | idp.example.org",| base64(hdr) || "kid": "key-2024-01" | "sub": "user123", | + "." + || } | "aud": "app-client"| base64(pay), || | "exp": 1702656000, | privateKey || | "iat": 1702652400, | ) || | "auth_time": | || | 1702652380, | || | "email": "user@ | || | example.org", | || | "groups": [ | || | "finance-team", | || | "all-staff" | || | ] | || | } | |+------------------------------------------------------------------+
eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczo...signature |___________________|________________________|________| Header Payload Signature (base64) (base64) (base64)Figure 3: OIDC ID token as JWT showing three-part structure
The JWT format is compact and easily parsed by any programming language with JSON support. A typical ID token is 800 to 1,500 characters, compared to SAML assertions that span 5,000 to 20,000 characters. This compactness makes OIDC suitable for mobile applications and APIs where SAML’s verbosity creates bandwidth and parsing overhead.
OIDC defines several authentication flows optimised for different application types. The authorisation code flow suits server-side web applications: the browser receives an authorisation code that the server exchanges for tokens via back-channel communication. The implicit flow (now deprecated for security reasons) returned tokens directly to the browser. The authorisation code flow with PKCE (Proof Key for Code Exchange) secures native and single-page applications that cannot protect client secrets.
Protocol Selection
Protocol choice depends on application requirements and existing infrastructure rather than intrinsic superiority of either protocol.
SAML remains necessary for many enterprise applications, particularly those developed before 2015. Legacy systems, government portals, and established SaaS platforms often support only SAML. Organisations cannot avoid SAML entirely without limiting application choices.
OIDC suits modern applications, APIs, and mobile platforms. New SaaS applications predominantly implement OIDC, and custom development should default to OIDC unless specific requirements mandate SAML. The protocol’s simplicity reduces implementation errors and simplifies troubleshooting.
Most identity providers support both protocols simultaneously, issuing SAML assertions to applications that require them and OIDC tokens to those that support them. The choice occurs at the SP level, not the IdP level, allowing organisations to adopt OIDC for new applications while maintaining SAML for legacy systems.
Federation Topologies
Federation extends SSO across organisational boundaries. Where internal SSO involves a single organisation’s IdP and applications, federation connects multiple organisations’ identity systems. The topology of these connections affects scalability, administrative burden, and failure isolation.
Bilateral Federation
Bilateral federation establishes direct trust between two organisations. Organisation A’s IdP trusts Organisation B’s IdP, and vice versa, enabling users from either organisation to access the other’s resources.
+------------------------------------------------------------------+| BILATERAL FEDERATION |+------------------------------------------------------------------+
Organisation A Organisation B+------------------------+ +------------------------+| | | || +------------------+ | | +------------------+ || | Identity | | Trust | | Identity | || | Provider A |<------------->| | Provider B | || +--------+---------+ | | +--------+---------+ || | | | | || +-----+-----+ | | +-----+-----+ || | | | | | | | | || +--v-+ +-v--+ +v--+ | | +--v-+ +-v--+ +v--+ || |App | |App | |App| | | |App | |App | |App| || | 1 | | 2 | | 3 | | | | 4 | | 5 | | 6 | || +----+ +----+ +---+ | | +----+ +----+ +---+ || | | |+------------------------+ +------------------------+
User from Org A can access Apps 4, 5, 6 via IdP B trustUser from Org B can access Apps 1, 2, 3 via IdP A trustFigure 4: Bilateral federation between two organisations
Bilateral federation works for single partnerships but scales poorly. Adding a third organisation requires two new trust relationships (A-C and B-C). Four organisations require six relationships. The number of relationships grows as n(n-1)/2, meaning 10 organisations require 45 bilateral trusts. Each relationship requires configuration at both ends, certificate exchange, attribute mapping, and ongoing maintenance.
Humanitarian consortia and implementing partner networks encounter this scaling problem. A consortium of 15 organisations coordinating a response would require 105 bilateral federation relationships, each requiring negotiation and technical configuration.
Hub-and-Spoke Federation
Hub-and-spoke federation introduces a central federation hub that brokers trust between organisations. Each organisation establishes a single trust relationship with the hub rather than with every other organisation.
+------------------------------------------------------------------+| HUB-AND-SPOKE FEDERATION |+------------------------------------------------------------------+
+--------------------+ | | | FEDERATION HUB | | (Broker/Proxy) | | | +----+----+----+-----+ | | | +-----------------+ | +-----------------+ | | | v v v+----------+--------+ +----------+--------+ +----------+--------+| | | | | || Organisation A | | Organisation B | | Organisation C || | | | | || +-------------+ | | +-------------+ | | +-------------+ || | IdP A | | | | IdP B | | | | IdP C | || +------+------+ | | +------+------+ | | +------+------+ || | | | | | | | || +----+----+ | | +----+----+ | | +----+----+ || | | | | | | | | | | | | | || +-v-+ +v-+ +v-+ | | +-v-+ +v-+ +v-+ | | +-v-+ +v-+ +v-+ || |App| |Ap| |Ap| | | |App| |Ap| |Ap| | | |App| |Ap| |Ap| || +---+ +--+ +--+ | | +---+ +--+ +--+ | | +---+ +--+ +--+ || | | | | |+-------------------+ +-------------------+ +-------------------+
Trust relationships: 3 (each org to hub)vs bilateral: 3 (would be same at 3 orgs, but at 10 orgs: 10 vs 45)Figure 5: Hub-and-spoke federation with central broker
The hub approach scales linearly: adding an organisation requires one new trust relationship regardless of how many organisations already participate. The hub also provides a natural point for policy enforcement, attribute transformation, and audit logging.
Several hub models exist in the humanitarian and research sectors. Research and education networks operate federated identity through hubs like eduGAIN, which connects national research federations globally. Humanitarian coordination mechanisms have explored similar models, though adoption remains limited compared to research networks.
Hub-and-spoke creates a single point of failure. If the hub becomes unavailable, all cross-organisational access fails. Hub operators must maintain high availability and clear governance around who controls policy at the hub level.
Mesh Federation
Mesh federation establishes multilateral trust through shared standards rather than bilateral agreements or central hubs. All participants agree to common policies, attribute schemas, and security requirements, enabling any participant to accept assertions from any other participant.
+------------------------------------------------------+| MESH FEDERATION |+------------------------------------------------------+
Shared Policy Framework +------------------------------------------+ | - Common attribute schema | | - Minimum security requirements | | - Incident response procedures | | - Audit and compliance standards | +------------------------------------------+ | | All participants agree | +-------------------+-------------------+ | | | v v v+-------+ +-------+ +-------+| |<--------->| |<--------->| || Org A | | Org B | | Org C || |<-----+ | | +----->| |+-------+ | +-------+ | +-------+ ^ | ^ | ^ | | | | | | +--------+--------+ | | | | +-------------------+-------------------+ | v +-------+ | | | Org D | | | +-------+
Each org trusts all others based on shared policy complianceNo central broker requiredFigure 6: Mesh federation through shared policy framework
Mesh federation requires substantial governance investment. Participants must agree on attribute semantics (what does “staff member” mean across organisations with different employment models?), security baselines (what authentication strength is acceptable?), and compliance verification (how do participants demonstrate ongoing compliance?). Research federations have invested decades in developing these frameworks.
The humanitarian sector lacks mature mesh federation infrastructure. Individual partnerships use bilateral federation; coordination bodies have explored hub models. Organisations seeking cross-organisational SSO must currently invest in bilateral or hub arrangements rather than joining established mesh federations.
Trust and Attribute Mapping
Federation trust encompasses more than cryptographic verification. The receiving organisation must translate assertions from the sending organisation’s context into its own authorisation model. This translation requires attribute mapping and semantic agreement.
Attribute Sources and Transformation
Identity providers include user attributes in assertions based on SP requests and IdP configuration. The IdP draws attributes from its directory or connected systems, transforms them according to configured rules, and includes them in the assertion.
A user’s directory entry might contain department: Finance and Administration while the SP expects department: finance. The IdP transforms the attribute value during assertion generation. More complex transformations derive attributes from multiple sources: a user’s effective permissions might depend on their role, department, project assignments, and employment status, computed at authentication time.
+-------------------------------------------------------------------+| ATTRIBUTE TRANSFORMATION |+-------------------------------------------------------------------+
Directory (Source) IdP Transform SP (Target)+-----------------+ +----------------+ +-------------+| | | | | || cn: Jane Smith | | Map cn -> name |-------->| name || | | | | || mail: jane@ | | Map mail -> |-------->| email || example.org | | email | | || | | | | || department: | | Lowercase, |-------->| department || Finance and |----------->| truncate | | finance || Administration| | | | || | | | | || memberOf: | | Extract group | | || CN=Finance, |----------->| names, filter |-------->| groups || CN=AllStaff, | | to SP-relevant | | finance || CN=Building2 | | | | staff || | | | | || employeeType: | | Derive from | | || FTE |----------->| type + dept |-------->| role || jobTitle: | | | | finance_ || Accountant | | | | user |+-----------------+ +----------------+ +-------------+Figure 7: Attribute transformation from directory to SP-expected format
Federation complicates attribute mapping because organisations define attributes differently. One organisation’s “manager” might mean people manager while another’s means project manager. Employment types, organisational units, and permission levels lack universal definitions. Federation agreements must specify attribute semantics or accept that receiving organisations will interpret attributes according to their own understanding.
Authorisation Decisions
SSO and federation handle authentication: verifying that a user is who they claim to be. Authorisation, determining what an authenticated user may do, remains the SP’s responsibility. The SP uses claims from the assertion to make authorisation decisions but is not bound by the IdP’s interpretation.
Consider a grants management system that restricts financial approval to users with the finance-approver role. The SP receives an assertion with groups: finance-team, budget-owners. The SP must map these claims to its internal authorisation model. Configuration might specify that membership in budget-owners grants the finance-approver role, or the SP might require an exact finance-approver claim and reject users who lack it.
This separation means that federation does not automatically grant access. A user from a partner organisation who authenticates successfully still requires the SP to recognise their claims and grant appropriate permissions. Federation without authorisation configuration produces authenticated users who cannot access anything.
Session Management
SSO introduces session complexity because sessions exist at multiple layers. The IdP maintains a session that persists across SP visits. Each SP maintains its own session tied to the user’s browser. These sessions have independent lifecycles and security properties.
Session Lifecycle
When a user first authenticates to the IdP, the IdP creates a session and issues a session cookie. Subsequent SP visits that redirect to the IdP receive assertions without re-authentication because the IdP session exists. Each SP creates its own session upon receiving a valid assertion, typically stored as a cookie with a server-side session record.
+------------------------------------------------------------------+| SESSION RELATIONSHIPS |+------------------------------------------------------------------+
Time | | User authenticates to IdP | +------------------------------------------+ v | IdP Session | | Created: 09:00 Expires: 17:00 | | (8-hour absolute timeout) | +------------------------------------------+ | | User accesses App 1 (09:05) | +--------------------------------+ | | App 1 Session | | | Created: 09:05 | | | Idle timeout: 30 min | | | Linked to IdP session | | +--------------------------------+ | | User accesses App 2 (10:30) | +--------------------------------+ | | App 2 Session | | | Created: 10:30 | | | Idle timeout: 15 min | | | Linked to IdP session | | +--------------------------------+ | | User idle on App 2 (10:45 - session expires) | +--------------------------------+ | | App 2 Session EXPIRED | | | User must re-access | | | (IdP session still valid, | | | so no password prompt) | | +--------------------------------+ | | User accesses App 2 again (11:00) | +--------------------------------+ | | App 2 NEW Session | | | Created: 11:00 | | | (Silent SSO - no login) | | +--------------------------------+ | vFigure 8: Session relationships showing IdP and SP session independence
SP sessions may expire independently of the IdP session. A user whose App 2 session expires at 10:45 can seamlessly re-access App 2 at 11:00 if the IdP session remains valid. The user experiences no authentication prompt despite the SP session expiring, because the IdP issues a new assertion based on the existing IdP session.
This behaviour has security implications. An SP that requires fresh authentication for sensitive operations cannot rely on session expiration alone. The user might have stepped away from their workstation for 45 minutes, long enough for the SP session to expire, but return and access sensitive data without re-authenticating because the IdP session persists. Sensitive operations should require step-up authentication regardless of session state.
Single Logout
Single logout (SLO) terminates sessions across the IdP and all SPs simultaneously. When a user logs out of one application, the logout propagates to the IdP and all other applications with active sessions.
SLO implementation is unreliable in practice. The IdP must track which SPs have active sessions and notify each one during logout. SPs must implement logout endpoints that destroy sessions upon notification. If any SP fails to respond, the user remains logged into that application despite logging out elsewhere.
SAML defines two SLO bindings: front-channel (browser redirects) and back-channel (direct server communication). Front-channel SLO requires the browser to visit each SP’s logout endpoint sequentially, which fails if the browser closes or the network interrupts. Back-channel SLO requires network connectivity between IdP and all SPs, which may not exist.
Organisations should not assume SLO works reliably. Security-sensitive contexts should implement session timeouts short enough that logout failures have limited impact. Users should close browsers rather than relying on logout to terminate all sessions.
Identity Provider Selection
Identity provider selection determines federation capabilities, integration options, and operational burden. The choice involves trade-offs between self-hosted control and managed service convenience, open source flexibility and commercial support, and jurisdictional considerations around data location.
Open Source Options
Keycloak provides comprehensive IdP functionality including SAML 2.0, OIDC, user federation, and social login integration. Red Hat develops Keycloak and offers commercial support through Red Hat SSO. Deployment requires Java hosting (typically Kubernetes or standalone JVM) and PostgreSQL or MySQL for persistence. Keycloak handles thousands of concurrent users on modest infrastructure: a two-node deployment with 4 vCPU and 8 GB RAM per node supports 10,000 active users with sub-second authentication latency.
Authentik offers a Python-based alternative with modern architecture and strong OIDC support. SAML support exists but receives less development attention than OIDC. Authentik deploys via Docker or Kubernetes and uses PostgreSQL. The project is younger than Keycloak with a smaller community, but development is active and documentation is thorough.
Kanidm takes a Rust-based approach focused on security and performance. The project is less mature than Keycloak or Authentik but offers interesting capabilities including integrated RADIUS support. Organisations with Rust expertise and tolerance for early-stage software may find Kanidm suitable; others should prefer more established options.
Self-hosted options require operational investment. Organisations must handle updates, security patches, backup, high availability, and incident response. This investment provides complete control over data location and processing, which matters for organisations with strict data sovereignty requirements or operating in jurisdictions where cloud services create legal exposure.
Commercial Options
Microsoft Entra ID (formerly Azure Active Directory) integrates tightly with Microsoft 365 and Azure services. Organisations using Microsoft 365 already have Entra ID; extending it for SSO to additional applications requires configuration rather than new infrastructure. Entra ID supports SAML and OIDC, includes conditional access policies, and offers premium tiers with additional security features. The platform is US-headquartered, and data may be stored in or accessible from the United States regardless of tenant location, creating CLOUD Act exposure.
Okta provides identity management as its core business rather than as an adjunct to other services. The platform supports extensive application integrations, sophisticated lifecycle management, and advanced security features. Okta is US-headquartered with similar jurisdictional considerations to Microsoft. Pricing scales with user count and feature tier.
Google Cloud Identity serves organisations using Google Workspace. Like Entra ID for Microsoft, organisations already using Google Workspace have Cloud Identity available. SAML and OIDC support enable SSO to non-Google applications. Google is US-headquartered with attendant jurisdictional implications.
Commercial options reduce operational burden but create vendor dependency and may not satisfy data sovereignty requirements. Organisations must evaluate whether operational convenience outweighs jurisdictional and lock-in concerns.
Selection Criteria
| Criterion | Key Questions |
|---|---|
| Protocol support | Does the IdP support protocols your applications require? Most modern applications need OIDC; legacy applications may require SAML. |
| Directory integration | Can the IdP connect to existing user directories (Active Directory, LDAP, HR systems)? What synchronisation options exist? |
| Federation capability | Does the IdP support incoming federation (accepting assertions from partner IdPs)? What federation topologies are supported? |
| Conditional access | Can the IdP enforce context-aware policies (device compliance, location, risk level)? How granular are policy controls? |
| Data residency | Where is data stored? Can you control data location? What jurisdictional exposure exists? |
| Operational requirements | What infrastructure and expertise does operation require? What is the failure mode if the IdP becomes unavailable? |
| Exit path | How would you migrate to a different IdP? Can you export user data and configuration? |
Partner and Consortium Federation
Mission-driven organisations frequently collaborate with partners, participate in consortia, and work within coordination mechanisms that benefit from federated identity. These scenarios require federation beyond internal SSO.
Partner Access Patterns
Partners may need access to specific applications without accounts in the host organisation’s directory. Federation enables this access through trust relationships between the organisations’ IdPs.
Consider an implementing partner organisation whose staff need access to the lead organisation’s grants portal. Without federation, the lead organisation creates accounts for partner staff in its directory, manages those accounts through their lifecycle, and handles password resets and access issues. With federation, partner staff authenticate against their own organisation’s IdP, and the lead organisation’s grants portal accepts assertions from the partner IdP. The lead organisation controls what federated users can access but does not manage their credentials.
+------------------------------------------------------------------+| PARTNER FEDERATION |+------------------------------------------------------------------+
Lead Organisation Implementing Partner+------------------------+ +------------------------+| | | || +----------------+ | Trust | +----------------+ || | |<--+----------+-->| | || | IdP | | | | IdP | || | (Keycloak) | | | | (Entra ID) | || +-------+--------+ | | +-------+--------+ || | | | | || +------+-------+ | | +------+-------+ || | | | | | | || +--v---+ +---v--+ | | +--v---+ +---v--+ || |Grants| |Mail | | | |Mail | |HR | || |Portal| | | | | | | |System| || +------+ +------+ | | +------+ +------+ || | | || Partner staff | | Partner staff || access Grants Portal | | use their own IdP || via federation | | credentials |+------------------------+ +------------------------+Figure 9: Partner federation enabling cross-organisational access
Federation agreements should address attribute expectations, access scope, security requirements, and incident procedures. What attributes will the partner IdP provide? What access will federated users receive? What authentication strength does the lead organisation require? Who is notified if a security incident affects federated access?
Consortium Identity
Humanitarian response consortia and similar coordination structures create identity challenges. Staff from multiple organisations need access to shared platforms (coordination tools, shared dashboards, joint case management). Creating accounts for hundreds of users across dozens of organisations in a central directory is administratively unsustainable.
Federation provides a scalable approach. The coordination body establishes federation relationships with participating organisations’ IdPs. Participating organisation staff access shared platforms using their home organisation credentials. The coordination body controls access based on claims from the home organisation.
This model requires participating organisations to have IdPs capable of federation, which smaller organisations may lack. Coordination bodies may need to provide IdP services (or access to a shared IdP) for organisations without internal capability.
Merger and Acquisition Identity
Organisational mergers create a period where two identity systems must coexist. Staff need access to applications from both legacy organisations while integration proceeds. Federation bridges this gap.
+------------------------------------------------------------------+| MERGER IDENTITY COEXISTENCE |+------------------------------------------------------------------+
Phase 1: Pre-merger Phase 2: Coexistence (Separate systems) (Federated bridge)
+----------+ +----------+ +----------+ +----------+| Org A | | Org B | | Org A |<--->| Org B || IdP | | IdP | | IdP |trust| IdP |+----+-----+ +----+-----+ +----+-----+ +----+-----+ | | | | +--+--+ +--+--+ +--+--+ +--+--+ | | | | | | | |+-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+|App| |App| |App| |App| |App| |App| |App| |App|| 1 | | 2 | | 3 | | 4 | | 1 | | 2 | | 3 | | 4 |+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Org A staff: A apps Org A staff: A + B apps (via federation)Org B staff: B apps Org B staff: A + B apps (via federation)
Phase 3: Integration Phase 4: Unified (Directory sync) (Single IdP)
+----------+ +----------+ +---------------+| Org A |<--->| Org B | | Merged Org || IdP |sync | IdP | | IdP |+----+-----+ +----+-----+ +-------+-------+ | | | +-------+-------+ +-------+-------+ | | | | +-----+-----+ +-v-+ +-v-+ +-v-+ | | |App| |App| |App| +-v--+ +-v--+ | 1 | | 2 | |...| |Apps| |Apps| +---+ +---+ +---+ | 1-4| | 1-4| +----+ +----+
Both directories sync, Single IdP, unified directoryeither IdP can auth All apps migratedto all appsFigure 10: Identity system evolution through organisational merger
The coexistence phase may last months or years depending on integration complexity. Federation allows immediate cross-access while directory consolidation proceeds in the background. Applications are migrated to the unified IdP incrementally rather than in a risky single cutover.
Implementation Considerations
SSO and federation deployment varies significantly based on organisational context. A single IT person supporting a small organisation faces different constraints than an established IT function implementing federation across a humanitarian consortium.
For Organisations with Limited IT Capacity
Start with cloud-hosted identity rather than self-hosted infrastructure. Microsoft Entra ID (if using Microsoft 365), Google Cloud Identity (if using Google Workspace), or a managed Keycloak instance reduces operational burden. The trade-off is reduced control over data location and processing.
Prioritise applications by security impact. Email and collaboration platforms benefit most from SSO because they contain sensitive data and are accessed frequently. Enable SSO for these first, then extend to other applications. A typical sequence: email and calendar, file storage, grants management, HR system, programme systems.
Use pre-built integrations wherever possible. Major IdPs offer application catalogues with one-click configuration for common SaaS applications. Custom SAML or OIDC configuration requires expertise that may be scarce; pre-built integrations reduce error risk.
Accept that some applications will not support SSO. Legacy systems, niche applications, and tools from vendors who have not invested in modern authentication may require local accounts indefinitely. Document these exceptions and implement compensating controls (strong unique passwords, regular access reviews).
For Organisations with Established IT Functions
Evaluate self-hosted versus managed IdP based on data sovereignty requirements, operational capacity, and cost. Self-hosted Keycloak provides complete control but requires infrastructure, expertise, and ongoing maintenance. Managed services reduce operational burden at the cost of vendor dependency and potential jurisdictional concerns.
Implement conditional access policies that enforce security requirements at authentication time. Block authentication from non-compliant devices, require MFA for sensitive applications, restrict access based on location or risk signals. Conditional access concentrates security policy at the IdP rather than distributing it across applications.
Plan for federation from the start even if immediate requirements are internal SSO only. Choosing an IdP with strong federation support and designing attribute schemas with external consumption in mind reduces rework when partner federation becomes necessary.
Invest in session monitoring and anomaly detection. SSO centralises authentication, which creates a valuable data source for security monitoring. Failed authentication patterns, unusual access locations, and session anomalies may indicate compromise attempts.
For Federated Organisational Structures
Country offices or affiliates with autonomous IT make different choices than headquarters. Federation between entities within the same organisational family requires the same technical mechanisms as federation with external partners but with potentially different trust levels and governance.
Establish common attribute schemas and naming conventions before implementing federation. Inconsistent attribute semantics create authorisation errors and user confusion. A user whose home entity asserts role: Finance and whose destination entity expects department: Finance will not receive expected access without transformation rules.
Document federation agreements formally. Who is responsible for user lifecycle management? What notification is required when a user’s employment ends? What security incident procedures apply to federated access? Informal agreements become problematic when incidents occur or staff change.
Trust verification
Federation trust is only as strong as the weakest participating IdP. A partner organisation with poor password policies or no MFA exposes all federated resources to credential compromise. Verify partner security posture before establishing federation trust, and include security requirements in federation agreements.