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.
Hits: 1643
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
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.