TRIRIGA Single Sign On with SAML

I intend this article to provide details on how to configure some of the more modern ways to do SSO for TRIRIGA in the cloud era.

Concepts

Single Sign-On (SSO) is a way to authenticate a user to the application via an enterprise identity repository. Seamless SSO inherits the users identity from a previously successful authentication attempt, to the same or a different application, that uses the same credentials.

Authentication is the process of establishing that the user is who they purport to be, whereas authorisation is the process of allowing that user access to various specific functionalities in the product.

SAML (Security Assertion Markup Language) is an open-standards, XML based statement that applications can use to make authentication and authorisation decisions. It is browser centric, in that it relies on browser redirects to function, and therefore is not well suited to back-end or machine-machine authentications, such as integrations. For this reason SAML SSO for any integrations, including business connect. the CAD Integrator and the Outlook Plugin, are not currently supported. For other reasons the UX and the Admin Console are also not supported, however SAML SSO may be achieved simply by first establishing a session using the standard UI.

SAML Identity Providers (IdP) are generally applications that authenticate users and create the associated SAML assertions to be sent to an associated service provider

SAML Service Providers (SP) are generally applications that consume SAML assertions created by the IdP and ether allow or deny access based on the content of that assertion

IdP initiated SAML is where the IdP sends an unsolicited SAML assertion to the SP. This is as opposed to SP initiated, whereby the SP would detect the absence of a SAML assertion and build an assertion request to be sent to the IdP.

TRIRIGA doesn’t do SSO

The TRIRIGA application itself doesn't do any of the heavy lifting involved in acting as either a SAML service provider. It instead expects the application server on which it sits to provide that layer. TRIRIGA expects the userid to be passed to it somewhere in the HTTP header and it trusts that the user has already been authenticated.

TRIRIGA supports three methods of inserting the userid into the HTTP header:

• Remote User
• User Principal
• Custom Attribute

TRIRIGA SSO Properties:

SSO: enable/disable SSO

SSO_REMOTE_USER: enable/disable RemoteUser

SSO_USER_PRINCIPAL: enable/disable User Principal Name

SSO_REQUEST_ATTRIBUTE_NAME: custom HTTP header attribute

SSO_REMOVE_DOMAIN_NAME: enable/disable domain stripping

USERNAME_CASE_SENSITIVE: enable/disable userid case-sensitivity

SAML SP in traditional WAS

These are the general steps to implement Websphere Application Server Full Profile (tWAS) SAML Service Provider. Note that the WebSphereSamlSP Trust Association Interceptor (TAI) only supports IdP initiated SAML, not SP initiated.

1. Install/Enable the WebSphereSamlSP TAI sample application using the included wsadmin thin client python script or the WAS console
2. Enable application server security
3. Configure WebSphereSamlSP properties manually, or import the IdP metadata
4. Trust your incoming realm, and trust the role
5. Restart the whole tWAS cell to implement

Troubleshooting:

• Use the TRIRIGA Admin Console requestTest.jsp page to decode the HTTP header getting passed by WAS.
• Enable the "com.ibm.ws.security.web.saml.*=all" trace via the WebSphere console and then monitor the trace.log while an authentication attempt is occurring.
• As additional certificate exchange may be required for HTTPS, I recommend initial tests using HTTP. A production implementation should, of course, always be implemented over HTTPS.

SAML SP in Liberty

These are the general steps to implement Websphere Application Server Liberty Profile SAML Service Provider.

1. Install samlWeb2.0 and co-requisite features by running the command:<tririgahome>/wlp/bin/installUtility install samlWeb-2.0
2. Enable samlWeb2.0 and co-requisite features by adding to server.xml
3. Enable and configure SSL
4. Configure samlWeb2.0
5. Restart and test

Troubleshooting:

• Enable AUDIT trace log
• Restart and test

Notes:

• Just like the tWAS TAI, the Liberty samlWeb2.0 SP only supports IdP initiated SAML
• The Target URL will need to be passed using the RelayState property

More Details

More details can be found on the developerWorks wiki.

For more details on SAML SSO, including setting up a test bed:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20TRIRIGA1/page/TRIRIGA%20on%20WebSphere%20with%20SAML%20SSO

For our TRIIRGA SaaS customers, the Cloud Delivery Services team will to all the heavy lifting:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Cloud%20Delivery%20Services%20-%20Maximo%20and%20TRIRIGA/page/Single%20Sign%20On%20(SSO)%2C%20SAML%2C%20LDAP