When enabling SAML authentication, we discovered that the documentation from HCL is not complete, perhaps because some links to IBM are no longer valid.
There are some important bits missing in the configuration.

This is the documentation from HCL: Authenticate using SAML

What is missing?

  • some custom properties in Global Security.
  • trusted authentication realms – inbound
  • several interceptor custom properties
  • Disable LTPAToken2 inbound

Global Security – Custom Properties

Parameter: com.ibm.websphere.security.DeferTAItoSSO
Value: com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor 

Parameter: com.ibm.websphere.security.InvokeTAIbeforeSSO
Value: com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor,com.ibm.ws.security.oauth20.tai.OAuth20.tai.OAuthTAI  

Parameter: com.ibm.websphere.security.performTAIForUnprotectedURI 
Value: true  

This last one is very important because we found out, after opening a CASE @HCL, that the login pages are unprototected. So SAML couldn’t redirect to a unsecure page, that’s not allowed.
The exact words from support: “This was set because the /login page was apparently not protected. But there may be a reason why this would not be protected (via the security-constraint section in the web.xml

And don’t forget to totally remove: com.ibm.websphere.security.disableGetTokenFromMBean
This parameter disallows WebSphere to distribute the Token between remote servers. So removing it it the solution.

trusted authentication realms – inbound

“Global Security” – “Federated Repositories” – “Trusted authentication realms – inbound”

Add both HTTP/HTTPS from your ADFS trust URL and your WebSphere REALM name in this section.

http://<adfsserver>/adfs/services/trust
https://<adfsserver>/adfs/services/trust

Interceptor custom properties

For the correct SAML handling, you need to add a new interceptor and several properties.

Create a new interceptor: “Global Security” – “Trust Association” – “Interceptors”
Name the new one: com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor

Parameter: sso_1.sp.acsUrl
Value: https://<connectionsserver>/samlsps/acs

Parameter: sso_1.sp.idMap
Value: localRealm

Parameter: sso_1.sp.filter
Value: request-url^=/homepage|/login|/service/authredirect.jsp;request-url!=forceLogin;request-url!=/login_redirect

Parameter: sso_1.sp.trustStore
Value: CellDefaultTrustStore

Parameter: sso_1.sp.targetUrl
Value: https://<connectionsserver>/homepage/web/login_redirect?redirectUrl=/homepage/

Parameter: sso_1.idp_1.entityID
Value: https://<adfsserver>/adfs/services/trust

Parameter: sso_1.sp.useRelayStateForTarget
Value: false

Parameter: sso_1.sp.login.error.page
Value:https://<adfsserver>/adfs/ls/IdpInitiatedSignon.aspx?loginToRp=https://<connectionsserver>/samlsps/acs

Parameter: sso_1.idp_1.singleSignOnUrl
Value: https://<adfsserver>/adfs/ls/

Parameter: sso_1.idp_1.certAlias
Value: <Fill in the ADFS-Certificate-Alias>

Parameter: sso_1.sp.useRealm
Value: <Fill in your Realm-name>

Parameter: sso_1.sp.enforceTaiCookie
Value: false

CORBA errors
Discovered a new strange behavior on Common | Homepage | PushNotification while SAML is enabled. Lots of CORBA NO_PERMISSION errors in SystemOut.log which indicates that there is no authenticated user to perform the requests.

Seems like LTPAToken is not working or is not set.

Browser error: We are unable to process your request

SystemOut logging: Cause is RMI exception: CORBA NO_PERMISSION 0x49424300 No; nested exception is:
org.omg.CORBA.NO_PERMISSION:

Solution:
In the WAS console > Global Security > RMI/IIOP Security > CSIv2 inbound communications > uncheck “Propagate security attributes”. This will disable LTPA2 support and cause WAS to lookup user information in LDAP instead of gathering from the server providing the LTPA2 token.

Visits: 1678

By angioni

2 thoughts on “Enable SAML with ADFS authentication for HCL Connections 6.5”
  1. Hi Remco,

    Nice piece of documentation. But how does SAML relate to external users? We have our internal users in AD, but the externals are in Domino. ADFS is only working for those AD users. Can the Domino users still login?

    Gert

    1. I would like to see yes, but i really don’t think that’s the case. SAML redirect will take over and prompt you for logging in into AD.
      When using external users, we advise you to use the same directory as for internal users, but choose a different OU for identifying them.
      It’s not hard to move the external users from Domino directory to AD. It’s a small process in SDI ( TDI ) to do that.

      When external users are moved to your AD, they receive a login prompt from the ADFS server, and not from Domino anymore.

      But, i will double check it and will reply with my findings.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.