Publicidad

Design Pattern for Federated Single Sign-On Access

Strategic Thinker, Problem Solver and Leader in Architecture en Cox Enterprises
2 de Dec de 2015
Publicidad

Más contenido relacionado

Similar a Design Pattern for Federated Single Sign-On Access(20)

Publicidad
Publicidad

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
Publicidad