How do you pass a SAML link in a work task notification email?


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.]

Continue reading

Can anyone help with a WebSphere SAML error?


Can anyone help me? What exactly is the fix for this issue? We are using WebSphere 8.5.5.9 version with IdP-initiated SAML.

[7/14/16 9:58:14:120 EDT] 000000cc ReplayManager 3 SAML Assertion with ID: _c79da00a-bcd7-405f-b1af-e1c5c4310f8a has been received in previous request.
[7/14/16 9:58:14:120 EDT] 000000cc ReplayManager E CWWSS8036E: A SAML assertion with ID [_c79da00a-bcd7-405f-b1af-e1c5c4310f8a] has already been received and processed.

This looks like it is happening outside of TRIRIGA: WebSphere Application Server 8.5.5: Messages: CWWSS.

CWWSS8036E: A SAML assertion with ID [{0}] has already been received and processed.

  • Explanation: A SAML assertion should not be replayed. The current request has a SAML assertion that has already been found in a previous request.
  • Action: Ensure the Identity Provider does not generate a SAML assertion with a duplicated ID or resend the same SAML assertion more than once.

Continue reading

Is there a way to implement SAML SSO with WebSphere Liberty?


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.]

Continue reading

Is there a way to have 2 channels of authentication with one IHS?


Our customer will have two channels of authentication via intranet:

  • 1. The users who have the smartcard will be authenticated through SAML SSO IdP (using WAS SAML TAI).
  • 2. The users who don’t have the smartcard will be authenticated through LDAP.

As I have understood, both channels could be accomplished by using the SSO mode of TRIRIGA. In SSO mode, TRIRIGA will use the SSO_REQUEST_ATTRIBUTE_NAME to identify the HTTP header attribute, which holds the username, but we can have only one SSO_REQUEST_ATTRIBUTE_NAME value per TRIRIGA instance. So we can’t directly handle the two channels within the same TRIRIGA instance, because the HTTP header attribute used by SAML SSO IdP and IHS LDAP could be different. Here’s my thinking:

  • Solution 1: One IHS with two “virtual hosts” point to two TRIRIGA instances. I think it will work with no problem.
  • Solution 2: One IHS with two “virtual hosts” point to the same TRIRIGA instance. Assuming that the SAML SSO IdP will send the username with the attribute defined in SSO_REQUEST_ATTRIBUTE_NAME. The virtual host on which the LDAP authentication is enabled will need to rewrite the HTTP header to adapt the setting of SSO_REQUEST_ATTRIBUTE_NAME. I’m not sure if it will work.

Ideally, we would like to handle the two channels with the same IHS and same virtual host (basically, the same URL). That would be easier for sharing the URLs between the end users. But I haven’t found the solution yet. Maybe we should use the ALTERNATE_INDEX_HTML? Is it possible? Thanks in advance for sharing your opinion about my solution. Any idea will be appreciated.

[Admin: For convenience, here are the meanings of the acronyms: Security Assertion Markup Language (SAML), Single Sign-On (SSO), Identity Provider (IdP), WebSphere Application Server (WAS), Trust Association Interceptor (TAI), Lightweight Directory Access Protocol (LDAP), IBM HTTP Server (IHS).]

[Admin: This post is related to the 02.10.16 post about SAML SSO in TRIRIGA.]

Continue reading

Having some questions about SAML SSO in TRIRIGA


Our customer wants to use SAML SSO within TRIRIGA. This wiki article shows the procedure to set up the SAML SSO using WAS TAI, and after testing, it works. But I have still have some questions:

  • 1. It seems that the “Sign Out” link in TRIRIGA doesn’t invalidate the SAML SSO token. Can we customize the “Sign Out” link to do a real “Sign Out” on the IdP side?
  • 2. The “sso_<n>.sp.useRelayStateForTarget” property allows WAS TAI using the RelayState sent from IdP. Does TRIRIGA support the “RelayState”?

[Admin: For convenience, here are the meanings of the acronyms: Security Assertion Markup Language (SAML), Single Sign-On (SSO), WebSphere Application Server (WAS), Trust Association Interceptor (TAI), Identity Provider (IdP).]

Continue reading