Design Pattern for Federated Single Sign-On Access
2 likes1,582 views
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.
Design Pattern for Federated Single Sign-On Access
- 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