We are using IdP-initiated SAML, and we access TRIRIGA via a link that looks something like this: http://idpprovider/applications/Tririga. Can we pass this link in FRONT_END_SERVER in TRIRIGAWEB.properties so that users can click on the link that they get in a work task email, and they can be redirected to TRIRIGA?
SAML does not support basic authentication for non-browser clients. This is a SAML limitation. See the following APAR IV88274 link.
[Admin: For convenience, here are the meanings of the acronyms: Identity Provider (IdP), Security Assertion Markup Language (SAML).]
[Admin: This post is related to the 08.18.16 post about lack of support for non-browser clients. To see other related posts, use the SAML tag.]
What is the IBM TRIRIGA support scope for SAML SSO with external assertions, SHA-2 encryption, and multiple principal names simultaneously? We need to implement SSO with SAML and want to know if there are any restrictions when running that with the IBM TRIRIGA product.
[Admin: This post is related to the 08.18.16 post about TRIRIGA support for SAML for non-browser clients, and the 06.03.16 post about implementing SAML SSO with WebSphere Liberty.]
Single sign-on (SSO) solutions need to provide a mechanism for basic authentication according to the documentation in the “Requirements for single sign-on requests in the TRIRIGA Application Platform” for the TRIRIGA CAD Integrator, BIM, and Reserve Outlook Add-in. SAML does not support this for non-browser-based applications.
SAML is a technology that was designed for browsers, not integration applications such as CAD Integrator, BIM, Reserve Outlook Add-in, or other integration technologies. 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 for its non-browser clients such as CAD Integrator, BIM, and the Reserve Outlook add-in. SAML and SmartCard/CAC do not support basic authentication for non-browser-based clients.
The best practice, if using SAML or SmartCard/CAC, is to authenticate directly to TRIRIGA on a separate process server or integration server as opposed to the SSO-enabled application server. These users will need to know their TRIRIGA user name and password to sign in with this solution. An alternative best practice would be to set up a separate non-SAML SSO solution for non-browser client users, which can support basic or NTLM authentication. Similarly, SmartCard/CAC users would need to know their SmartCard/CAC user name and password to sign in with this solution.
[Admin: The same article is also posted in the IBM TRIRIGA blog and Watson IoT Support blog.]
I’m posting this for awareness. The WebSphere SAML SSO feature only works with an IdP-initiated SSO. (Refer to this article: Understanding the WebSphere Application Server SAML Trust Association Interceptor.) The IdP must be aware of the SP Entity Id as well as the RelayState which is the URL to which the browser is forwarded upon successful assertion by the WebSphere SAML SSO. (Refer to this guide for further SAML SSO configuration: Configuring SAML Web Browser SSO in Liberty.)
I confirmed that the following configuration works for SimpleSAML IdP when the user goes to the Id’s URL…
[Admin: For convenience, here are the meanings of the acronyms: Security Assertion Markup Language (SAML), Single Sign-On (SSO), Identity Provider (IdP), Trust Association Interceptor (TAI), Service Provider (SP).]
[Admin: This post is related to the 03.07.16 post about two channels of authentication with one IHS, and the 02.10.16 post about SAML SSO in TRIRIGA.]
Configuring secured SAML with WebSphere requires web pages to be protected. The design of the TRIRIGA application does not currently allow you to set up the EAR or WAR (depending on TRIRIGA platform release) to include web page protection. The ability to protect the web pages in this manner would require a major change in the TRIRIGA platform, so this would not be viewed as a defect, but as an enhancement.
So, what can I do to get this level of security? Your best option is to check the Request For Enhancement (RFE) site to see if someone has already requested that this be required in a future release. If an RFE exists, vote for it. The more votes an RFE has, the more likely it is to be included in a future release. If an RFE does not exist, create one and be sure to go to the Service Management Connect (SMC) forum and solicit votes for your enhancement request. Below is information about the RFE process that I provide to customers when a PMR leads to this sort of issue…
Our customer has a security constraint regarding graphics (drawings) access in TRIRIGA (not CAD Integrator/Publisher, but TRIRIGA). The security leader of this customer is asking to control the level of authentication for people who will have access to graphics (drawings) within TRIRIGA. This control should be done during the login. The security leader doesn’t care about TRIRIGA access control within TRIRIGA. He wants to control it before the login.
The authentication level is coming from their SAML SSO platform and the rule that determines whether or not this user has access to the drawing is stored in TRIRIGA. This rule is simple: Does this user belong to the TRIRIGA Architect group?
- Question 1: Is it possible to develop something in order to check the following rules during the login process?
- If this user belongs to the TRIRIGA Architect group and the authentication level from SSO is Medium, then TRIRIGA access is denied.
- If this user belongs to the TRIRIGA Architect group and the authentication level from SSO is High, then TRIRIGA access is granted.
- Question 2: If yes, is it possible to use it for the TRIRIGA login via the web browser as well as the TRIRIGA login via CAD Integrator/Publisher in AutoCAD?