Applicable Doc. 5D - IAM Playbook - SSOe.pdf

Last modified at 9/15/2023 1:47 PM by Vessels, Perry L. (Argil Solutions)

IAM Playbook Home

SSOe Playbook This (and all IAM playbooks) playbook is a collaborative and continuously improved wiki/document. The purpose of the wiki/document is to provide as much useful technical information to integrating partners, if there is information that you feel is missing please let us know and we can add it or even give you contributor rights to add the information yourself!

Applications interested in using any of the IAM services should submit a service request (SR) using the Information Technology Request Portal (ITRP) to start the process.

References AcS Common Business Rules - provides details on SSOe business rules (see Section 2.1)

SSOe Authentication Traits Access Assurance Policies

Enterprise Design Patterns Single Sign-on Multi-factor authentication Federation

Policy or System Constraints Support for external clients using the HTTP verbs PUT, DELETE, TRACE is available upon request

Overview IAM Single Sign-On External (SSOe) is the enterprise authentication solution for external users (e.g.

Veterans, beneficiaries, business partners). SSOe provides enterprise federated single sign-on (authentication and session management) to allow access to VA applications. Authentication is based on users authenticating using one of the integrated federated credential providers (e.g. DS Logon, ID.me).

IAM SSOe also includes a front-end site, AccessVA, that provides information to end users and a credential selection user interface for use by integrated applications.

IAM SSOe is Internet accessible in ALL environments in order to support proper testing across all of the environments.

Function Description Supporting Interfaces

Authenticate External User Allows a user that is authenticated at a federated CSP (IdP) to seamless access integrated applications

Application Junction Re-Assertion Partner CSP/IdP Federation Partner SSOe OAuth

Manage User Session Provides a session management service for the SSO environment, which includes user identity data, idle, and max use timeouts

Application Junction SSOe OAuth

Enforce Coarse-Grained Authorization

Provides enforcement of coarse-grained access control decisions and grants or denies access to

Application Junction Re-Assertion Partner

Page Rating

Categories No categories were selected

IAM Playbooks

SSOe https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/_layouts/listform.aspx?PageType=4&ListId={FC3D90CA-C60C-44F7-9901-1C022384F074}&ID=29 https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/IAM%20Playbook%20Home.aspx https://dvagov.sharepoint.com/sites/CMDM-RP/SitePages/What-is-ITRP-.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/AcS_Common_Business_Rules_Document.pdf https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/SSOe%20Authentication%20Traits.aspx https://digital.va.gov/office-of-information-and-technology/reference-library/enterprise-design-patterns/ javascript:;

javascript:;

javascript:;

javascript:;

javascript:;

https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/IAM%20Playbook%20Home.aspx

Function Description Supporting Interfaces information resources. Typical authorizations are based on Level of Assurance (i.e., only users authenticated with LOA3 or greater).

SSOe OAuth

Issue STS Token Provides the ability to obtain an STS token representing the authenticated user SSOe STS

Proxy Web Service Provides an additional layer of security to protect web services by providing schema validation, system authentication, and authorization

WS Client WS Producer

From a user flow perspective, the following diagram depicts a high level top-down flow through the SSOe system.

Phase 1 - App/CSP Navigation

For the initial user login, the navigation to the application starts with the user at the AccessVA website (AccessVA Full Page Mode) or with the user at the application’s home page. If the user starts at the application then the application may either initiate login by redirecting the user to AccessVA or through the use of an iframe presenting the AccessVA login widget to the user (AccessVA Widget Mode).

More information on AccessVA page.

Phase 2 - Authentication

Using any of the AccessVA modes as described above, the user selects a Credential Service Provider (CSP) to initiate the login process. This initiates the SAML 2.0 WebSSO login flow. The user would authenticate, according to the rules appropriate for the level of assurance for their credential, and once verified by the CSP will be sent back to the SSOe system with a SAML token. SSOe receives the SAML token, decrypts, verifies the digital signature, and if all is good initiates the next process.

A list of the current Sign-In Partners (CSPs) can be view on AccessVA (https://eauth.va.gov/accessva/about/signinpartners). It should be noted that the CSP is known as the IDP (Identity Provider) in the SAML 2.0 terminology.

Phase 3 - Enterprise Identity Resolution & Credential Binding https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/AccessVA.aspx https://access.va.gov/accessva/about/signinpartners

Having a user, represented by the SAML token asserted from the CSP, the next step for SSOe is to determine the identity of the user with respect to the enterprise. For this, SSOe uses the VA Enterprise Identity System known as MVI. SSOe first looks to see if the user’s is already known, if so, an immediate return of the users identity traits are provided and this data along with other CSP and system data are used to establish a session for the user. If the user is not known, the user is either Soft-Boarded (special case for credentials from MVI identity partners) behind the scenes or sent to the Confirmation page where more information can be collect and a record found from this extra data or a new record is created. In either case, a user that goes through confirmation must logout and log back in at which point they’ll be bound to the new identity and moved into session management.

Session Management - Session Management

Once a user has been moved into session management, that user is available for use within the various Integration Patterns. Session management holds all of the authentication traits for the authenticated user while the session is active. This session management layer also enforces VA 6500 and NIST 800-53 Session Management security controls for Session Timeout (AC-11: Session Lock) and Logout (AC-12:

Session Termination).

More information on Session Termination (timeout and logout) page.

SSOe also provides the following access enforcement mechanisms:

HTTP access validation using the SSO session token Validation that user meets minimum level of assurance as approved for application Validation that user is from a CSP supported by the application (new application should be credential agnostic - all credentials accepted)

Integration Patterns Based on the existing application architecture, there are different integration patterns for leveraging the SSOe service. The following diagram is a decision tree with questions and related guidance for how applications should integrate with the SSOe service. The Standard Junction is the preferred integration pattern, but for applications hosted outside the VA firewall the SAML Re-Assertion Provider pattern may be needed. Additionally, applications integrated with SSOe for user authentication are also added to AccessVA. AccessVA provides users with a simplified logon experience to VA resources and web applications. The purpose of AccessVA is to centralize user access and allow for easy logon to VA web applications. AccessVA also provides an authentication widget that can be used by applications to present the authentication options to the user without requiring a redirect to the full AccessVA site.

Pattern What does it do?

https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/Session%20Termination.aspx

Application Junction

APPLICATION JUNCTION PATTERN IS DISCONTINUED AND IS

NO LONGER AVAILABLE FOR NEW INTEGRATIONS

It allows authenticated SSOe session users to pass to the application across a mutually authenticated TLS channel, provided the session user passes the access control and authorization checks.

Re-Assertion Provider

(SAML)

An SSOe SAML partnership where SSOe is the IdP, and the application is in the SP role. SSOe uses a previously authenticated session user as the subject for this IdP and generates a new SAML token for the partner application.

CSP/IdP Federation Partner

SSOe handles user authentication through an approved CSP.

The CSP take responsibility for registration, identity proofing, credentialing, token management and initial authentication of the supported user base. After authenticating a user, the CSP provides to SSOe, either indirectly or directly, a SAML token containing the identity of the user along with the agreed upon attribute data.

SSOe Secure Token Service

(STS)

SSOe STS provides applications a method for obtaining a token for an authenticated user to pass in service calls. The interfaces for the STS service include WS-Trust messaging using SOAP with returned SAML token or REST with returned JSON token.

The STS supports "indirect" token exchange with approved application partners using the IAM SSOe session token.

SSOe OAuth SSOe OAuth 2.0 service, which provides client applications a “secure delegated access” to server resources on behalf of a resource owner. It is specifically implemented to support mobile applications.

WS Client Configuration to support an application client access to a provisioned gateway for a producer. The type of client accessing the service is dependent on the “service” the producer is offering and can thus be an application/system or a single user.

WS Producer A web service security proxy/gateway in front of a web service producer with a defined WSDL. It includes building the TLS authentication model and authorization controls.

Testing SSOe Integrated Applications Application developers and testers please see the SSOe Test Information playbook page for information about obtaining credentials and testing your application with SSOe.

SSOe Troubleshooting and Error Codes https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/Application%20Junction.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/Re-Assertion%20Provider%20%28SAML%29.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/SSOe%20Secure%20Token%20Service%20%28STS%29.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/OAuth/OAuth.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/Web%20Service%20Client.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/SSOe/SSOe%20Test%20Information.aspx

Application developers, operations staff and helpdesks should review the SSOe Troubleshooting and Error Codes page for information about the various SSOe error codes and their associated troubleshooting steps.

https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/ssoe/SSOe%20Troubleshooting.aspx