The document outlines the federated enterprise single sign-on (SSO) architecture design pattern, detailing components and their interactions in a software system. It emphasizes the use of SAML 2.0 as the industry standard for federated SSO and describes supported use cases, security measures, and the architecture involving identity and service providers. Key processes such as identity exchange, authorization, and real-time registration are also summarized.

1. Federated Enterprise Single Sign-On
Architecture Design Pattern – Tier 1 Solution Building Block Version: 1.0 Author: Mike Reams Last Modified:
Design Pattern
Federated
Single Sign-On
(SSO)
A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes
commonly recurring structure of communicating components that solves a general design problem within a particular context . Architectural patterns are
similar to software design patterns but have a broader scope. The architectural patterns address various issues in software engineering, such as computer
hardware performance limitations, high availability and minimization of a business risk.
Federated SSO The Industry Standard is SAML 2.0 with Organizational Standard of assertions use SAML 2.0 Post Bindings. Supported use cases are (1) IdP
Initiated; (2) SP Initiated; (3)IdP Trusted; (4) SP Real-Time Registration;
Preference is to Sign both the SAML Assertion Request & Response. With PII data, entire xml must be encrypted end-to-end over the SOAP channel.
SP=Service Provider | IdP=Identity Provider
Architecture Domain(s) Identity Management | Security | Middleware
Web Server (SP)
Access
Manager
Access Policy
General Architecture
Assertion
Consumer Service
(ACS)
Service
Provider
Service Provider
Initiated (SP)
Web Service
Metadata
Exchange
Invokes IdPInvokes SP
Identity Provider
4. IdP posts SAML Response with 10 digit ID
SP Trusted
User
IdP Trusted
User
Guest
User
Service Provider
B. Certificate & URI exchange (Build Trust)
1. User invokes a Service Provider (SP) protected URL
2. SP sends user to IdP with SAML Redirect Post Request
3. User enters credentials on IdP Login page
1. User invokes IdP protected application
A. Identity Exchange
6. SP grants authorization Application
5b. SP trusted user is redirected with an IdM SAML assertion to access SP
3. User enters credentials on IdP Login page
2. IdP sends guest user to Login page (challenge URL)
Assertion Consumer
Service (ACS)
4. IdP posts SAML Request with a valid 10 digit ID
Application
6. IdP user is authorized w/ token to access SP
5a. SP trusted user is registered real-time if not found
5. IdP Creates token for On-Prem Access