IBM Verify Identity Governance web services in a single sign-on environment

The single sign-on (SSO) application in the IBM Verify Identity Governance installed example directory, achieves single sign-on by using the IBM Verify Identity Governance web services.

The SSO application fetches the Lightweight Third Party Authentication (LTPA) token from the Hypertext Transfer Protocol (HTTP) header. The LTPA token serves as an identity token for using and maintaining the authenticated user information. The token enables the user to access the resources without requiring to log in to the IBM WebSphere Application Server again. The SSO application inserts this token into the SOAP header and then makes a web service call.

IBM Verify Identity Governance installation configures ISIMSecurityDomain as its security domain that scopes to the IBM WebSphere Application Server where the IBM Verify Identity Governance is deployed. Any application that runs on the same WebSphere® Liberty uses the ISIMSecurityDomain. Any application that runs on a separate WebSphere Liberty runs under a separate domain and the user security realm must be configured as trusted realm in ISIMSecurityDomain.

The SSO application uses form-based login when it is not accessed from a WebSEAL junction. IBM Verify Identity Governance users can log in to the sample application by using the same credentials as the IBM Verify Identity Governance account. The SSO application runs on the same WebSphere Liberty and uses the ISIMSecurityDomain. When deployed in a separate server than IBM Verify Identity Governance, the SSO application must be configured to share the IBM Verify Identity Governance user registry. Upon successful authentication, the SSO application receives an LTPA cookie in the response header from the WebSphere Liberty. The sample application extracts the LtpaToken2 cookie from the Hypertext Transfer Protocol (HTTP) header and sets it in the session. The WebServiceCall servlet starts the getPrincipalPerson web service API.

When the SSO application is accessed from a WebSEAL junction, the TAI (Trust Association Interceptor) prevents WebSphere security from requiring multiple authentications. IBM Verify Identity Governance users can log in to the sample application by using the credentials from the WebSEAL authentication server. Because the SSO application is deployed with the same ISIMSecurityDomain in the same WebSphere Application Server, the SSO application can log in to IBM Verify Identity Governance seamlessly with the LTPA token from WebSEAL. When run on a separate WebSphere Application Server, the SSO application must run under a separate domain and the user security realm must be configured as a trusted realm in the ISIMSecurityDomain.

The SSO application demonstrates that you can achieve SSO authentication with the IBM Verify Identity Governance web services in various deployment scenarios by using the WS-Security header. Modify the SOAP message to add the WS-Security header BinarySecurityToken. The BinarySecurityToken element has the LTPA identity token embedded. Provide the WS-Security header with the actor attribute, http://services.itim.com/60/actor, to enable the IBM Verify Identity Governance web services for processing the security header. Modify the SOAP message with the outgoing request of the ClientHandler.