Requirements for and limitations of SSO requests in TRIRIGA Application Platform

In an SSO environment, the user name and password that the user enters must match the user name and password that are stored in the directory server. The application server or web server then authenticates the user and inserts the user name into the HTTP request header.

The user name in the HTTP request header must exactly match the user name that is stored in the IBM TRIRIGA database. When configured properly, IBM TRIRIGA reads the user name from the request header and internally authenticates it against the IBM TRIRIGA database.

IBM TRIRIGA supports the following methods of inserting the user name into an HTTP header:
  • Remote User - The web server or application server authenticates the user and puts the user name in the REMOTE_USER HTTP header. The Java™ call is request.getRemoteUser().
  • User Principal - The web server or application server authenticates the user and puts the user name in the special UserPrincipal HTTP header. The Java call is request.getUserPrincipal().getName().
  • HTTP Header - The web server or application server authenticates the user and puts the user name in a specific named HTTP header attribute.
In addition to the insertion methods, IBM TRIRIGA supports several options for the user name after it is retrieved from the HTTP header:
  • Removal of Domain Name - In some SSO environments, the LDAP Domain Name is provided along with the user name, however, only the username portion is configured in the IBM TRIRIGA database. If the full string in the HTTP header is provided in the form of MyCompany\username, enabling this feature strips MyCompany\ or the domain portion from username.
  • Case Sensitivity - Some directory servers supply the user name in a mixed case, depending on a number of conditions. By default, IBM TRIRIGA user names are case-sensitive. If it is determined that the directory server is providing user names with mixed cases, you can disable the case-sensitive check in the SSO process.
Considerations:
  • If you are using a web server to provide the authentication portion, disable the HTTP port on the application server after the web server configuration completes. Keeping the application server's HTTP port open might create a vulnerability point. If the HTTP port is not disabled and the user goes to that port, the user is prompted for their credentials and the user name and password are verified in the IBM TRIRIGA database.
  • IBM TRIRIGA is compatible with SSO when SSO is configured properly. After the appropriate IBM TRIRIGA properties are enabled for SSO, IBM TRIRIGA can accept tokens that are provided by properly configured application servers with SSO. IBM® Support can assist with configuring IBM TRIRIGA properties for SSO. However, due to the number of supported products, technologies, and configurations that are supported by IBM TRIRIGA, IBM Support cannot help with the configuration of SSO within your environment.
  • If you enable SSO and attempt to launch a UX application with the non-SSO URL, you will not be automatically logged in through SSO nor get a login screen. You will be presented with a message indicating that you "Cannot log in to IBM TRIRIGA as you do not have a valid user." Make sure that you are using the SSO URL to access the UX application.
Limitations:
  • For its non-browser clients, IBM TRIRIGA does not support Security Assertion Markup Language (SAML) or credential-less login mechanisms such as SmartCard or Common Access Card (CAC) as a method of authentication.
    • Unsupported non-browser clients include the following clients:
      • IBM TRIRIGA CAD Integrator/Publisher
    • SSO solutions must provide a mechanism for Basic Authentication for non-browser clients. SAML and SmartCard or CAC do not support Basic Authentication for non-browser based clients.
    • The best practice if you are using SAML or SmartCard/CAC is to authenticate directly to IBM TRIRIGA on a separate process server or integration server as opposed to the SSO enabled application server. This solution requires users to use their IBM TRIRIGA user name and password to log in.
    • An alternative best practice is to set up a separate non-SAML SSO solution for non-browser client users, which can support Basic or NTLM Authentication. This solution requires SmartCard/CAC users to use their SmartCard/CAC user name and password to log in.
    • IBM TRIRIGA Connector for BIM 3.7.0.1 and 3.8.0, and IBM TRIRIGA CAD Integrator/Publisher 12.8.0 support browser-based interactions with SSO solutions. Although no specific solution is supported, in most cases, if a browser-based authentication flow results in a successful IBM TRIRIGA portal login, it can also be used for a BIM Connector or CAD Integrator login. These applications use an embedded version of Microsoft Internet Explorer 11 for the authentication flow. To the extent that SmartCard and similar solutions can integrate with the embedded IE 11, they can be used for a BIM Connector and CAD Integrator login.
  • Effective 2020-2021, Microsoft disabled Basic Authentication with Microsoft 365 Exchange Online services. As an alternative, Microsoft supports the OAuth open standard to connect to Microsoft 365 Exchange Online services.
  • Due to authentication requirements, the upload process no longer batches uploads when you use NTLM Authentication with IBM TRIRIGA CAD Integrator/Publisher. Also, the upload process for NTLM no longer provides progressive messages, for example, Uploaded 10 of 100 spaces. The upload process message for NTLM now displays Uploading spaces. This change does not impact the progressive feedback of other authentication schemes.
  • IBM TRIRIGA Advanced Room Search does not support Identity Provider (IdP) initiated SSO. It only supports Service Provider (SP) initiated SAML, OAuth, or OpenID Connect (OIDC) SSO.
  • For IBM TRIRIGA Application Platform 4.0 (both SaaS and On-Prem): When single sign-on (SSO) is implemented in a specific IBM TRIRIGA application server, native (internal) authentication is disabled for the standard browser-based interfaces. This means that you can no longer have one set of users authenticate natively and another set using SSO for that specific application server.
    • Native authentication may still be allowed via another application server where SSO is not enabled such as, for example, a process server.
  • For IBM TRIRIGA Application Suite (TAS): When single sign-on (SSO) is implemented in IBM TRIRIGA, native (internal) authentication is disabled for the standard browser-based interfaces. This means that you can no longer have one set of users authenticate natively and another set using SSO.
    • SSO is supported where it uses either Security Assertion Markup Language (SAML) or OAuth-based OpenID Connect (OIDC). Only a single configuration may be enabled for an environment, and this is automatically applied to all IBM TRIRIGA pods running in that namespace.
    • OIDC is strongly recommended as the preferred option for SSO. The reason is because SAML can only be configured for a single route, whereas OIDC supports multiple routes in a single configuration.