Debug parameters
If SAML doesn’t work you will probably get Bad SAML Request [/names.nsf?SAMLLogin] in the Domino server console. The first thing you need to do is to add some debug parameters to Domino, the easiest way is to write them on the domino console but you can add the directly into notes.ini or using the configuration document in the Name & adressbook.
set configuration DEBUG_SAML=31
set config WEBAUTH_VERBOSE_TRACE=1
When settings have been enabled you will see a lot more information on the domino console and with in this you will find clues what could be wrong with you SAML setup.
Set the debug parameters to 0 to turn them off
HCL article about debug parameters
Session provider id
The first thing I check is what is written in the Service provider ID field against what is written on the provider side in ADFS, Okta, Azure or some other SSO provider. This information must be 100% the same so http vs https will brake it or a trailing slash.
SP Certificate
Another thing to check if you get strange problems with creating the SP certificate, is to always set your self as full administrator before creating the certificate. Why you might ask, well this is because the action will run code on the server to add the new certificate into the server id and without maximum rights you might run into problems when creating the certificate.
Export SP Certificate for encrypted SAML Requests
If the Idp site config uses encryption on the SAML requests you need to export the SP certificate and place it either in the Domino html folder in the server or add it to a database and use the redirect url functionality on a website configuration or send it to the Idp Administrator.
Office 365 / Azure requires HCL Domino 10 or newer
Connecting to Office 365 / Azure, If you have a Domino server prior to version 10 and want to connect this to Azure Enterprise applications using SAML that will not work, trust me I have tried.
You need at least Domino 10 and the new design of the IDP database with the option AuthnRequest SAML 2.0 compatible.
Multiple SAML logins gives problems
Another interesting findings of mine when implementing SSO Login for customers applications was that one of the sides in Azure or Domino doesn’t keep track of multiple SAML Logins, this show it self as when multiple logins is started only one login response will be returned. I.e if you have embedded multiple Domino iframes on a single webpage they might break due to this, you need to add some thing so only one login request is handled at one time.
As you might understood by now, I can keep going with this due to the amount implementations of SSO I’ve done for clients both in their environment and against our Saas solution QNova Suite or our service eDomino.
Setting up SAML with Okta as Idp for HCL Domino
Next Implementation is Okta you might run into problems decrypting the SAML data and get one of these errors if you have enabled the extended debug above.
SECCheckAndParseSAMLResponse> VerifyResponseSignature : The encrypted data has been modified or the wrong key was used to decrypt it
SECCheckAndParseSAMLResponse> VerifyAssertionSignature : The encrypted data has been modified or the wrong key was used to decrypt it
SECCheckAndParseSAMLResponse> Signature verification check failed : Could not verify cryptographic signature
SECCheckAndParseSAMLResponse> Exiting : The encrypted data has been modified or the wrong key was used to decrypt it
And you go in to the federation metadata xml file that you have downloaded from Okta. and check the certificate and everything looks ok and you wounder what is wrong isn’t Domino and Okta compatible with each other. Yes, they are well you need to be using HCL Domino 10 and above besides that there is a problem in the xml file, so open up the xml file that Okta has provided check each line in the certificate section and you will see that it’s ended with CRLF so the solution is to remove all CRLF with in the X509Certificate section of the XML file and save it and after that do the setup.
Multiple certificates in the Federationmetadata.xml file
Update from the community, if the metadata xml file contains multiple certificates Domino will use the last one so if the file contains multiple certs make sure that HCL Domino picks up the correct one otherwise you will get “The encrypted data has been modified or the wrong key was used to decrypt it” error.
Thanks for the info Jeffrey Redding
Getting a login loop when a user login
If you get a login loop when a user is trying to login then there is possibly a domain issue on you LTPA token cookie or that you or your Idp is ending up on the wrong protocol http/https and that is restricting cookies.
This is some of my SSO SAML findings connected to HCL Domino comment below if you have found some quirky thing when you have done setups.
Time Synk problems will give you a BAD SAML REQUEST
Time synk is very important to get the SAML login requests to run smoothly, without an accurate time they will fail anf give error messages like the one below.
SECCheckAndParseSAMLResponse> Exiting : Single Sign-On token has a creation time in the future. Single Sign-On servers may need to have clocks synchronized.
SECCheckAndParseSAMLResponse failed with error: Single Sign-On token has a creation time in the future. Single Sign-On servers may need to have clocks synchronized.
Error in SAML response – Single Sign-On token has a creation time in the future. Single Sign-On servers may need to have clocks synchronized.
SAML login / authentication no redirect
in Domnio 12 users is redirected to the root or default specified url all the time.
so internal resource linking doesn’t work. Samesite cookie is what is causing this post explains how to fix it Login problems using SAML Domino 12
