Domino Authentication via SAML – All Flavours

For the Engage 2022 event, I prepared a “Domino Authentication via SAML – All Flavours” session, to present it with my colleague Herwig W. Schauer. Alas, the session never got accepted and I never had time to convert it to a whitepaper. As I invested quite a bit of time for preparing the slides, I thought that I should upload it here before it inevitably travels into oblivion. Maybe it will come handy for some of you.

Keep in mind that it was created in 2022 and there are some things I would have to change, for example, the following diagram is not 100% accurate:

Let me know if this topic is still of interest, I could update the presentation and do a webinar or just write a whitepaper…

Milan Matejic – SAML Deck-for-SharingDownload

Basic SAML – Demo

Basic SAML incl. SSO – Demo

Web Federated Login – Demo

Notes Federated Login – Demo

Notes Federated Login – Subsequent Login

HCL Nomad SAML – Initial Configuration

HCL Nomad SAML – Subsequent Login

HCL Traveler – SAML Enabled – New Device

HCL Traveler – SAML Enabled – Encrypted Mail

Domino 10.0.1 – IdP Catalog Database and the German Language Pack

If you are running Domino 10.0.1 Servers with German Language Pack and trying to implement SAML authentication mechanism, make sure to switch to the English version of the IdP Catalog database.

Or else you could run into the problem with creating the Service Provider Certificate by using the “Create SP Certificate” button in the “IdP Configuration” document, this action will create the certificate, but it will not create the “ServiceProvider.xml” file. When doing so, I got the following error:

Agent message: CreateIdPXML error 91 (Object variable not set) line 19 Please pass this error message to your notes admin

We had this issue in two customer environments, using Domino Version 10.0.1 to 10.0.1 FP3.

Domino AppDev Pack – Obstacles in using IAM Server for Authentication with WordPress, Drupal & Co.

One of our customers would like to use Domino as a User repository to Authenticate his users against services like WordPress and Drupal. The first thing that crossed my mind was Domino AppDev Pack and OAuth 2 Protocol. We decided to Deploy the AppDev Pack 1.0.1 (later on I upgraded the package to the 1.0.2 version) in a test environment and test this out.

The deployment is not that hard, the preparation of SSL Certificates is the key. For the Proton Task you need to create a self-signed certificate and generate some user certificates using the same CA you created for the Proton task. For everything else, you need a valid public SSL Certificate (including the client Application, WordPress for example). A big thumbs up for my colleague Christian Brandlehner for the heads-up. This is the first thing to keep in mind.

I am thinking about posting a step-by-step guide on how to deploy the environment we needed, so let me know if you are interested.

My first big issue was finding a WordPress Plugin which we were able to use with Domino IAM as endpoint. Most of the plugins available in the WordPress store can not be used in that regard. For me, only the WordPress plugin from MiniOrange was a viable option, they also have an awesome support.

After choosing and configuring the plugin I started getting various errors, like “client authentication failed” or “callback URL mismatch“. I contacted Heiko Vogt who helped me with troubleshooting, but after a some time I opened a case at HCL Support site. Here I got the information that most of the third party Software or Plugins for OAuth 2 will fail if there is a “+” or “%” sign in the Client Secret (this is by no means a bug or error at IAM component). That was the next challenge, because you can not restrict the Domino IAM on which characters to use when creating a Client Secret for the OAuth mechanism. Here you have to be patient and generate a few Applications on IAM until you get one without “+” or “%” characters in the Client Secret.

One more thing, you have to make sure that the “Callback URL” is the same in IAM Application definition and in the WordPress plugin, including any trailing slashes, this is the reason for “callback URL mismatch” error.

After a client secret with which the plugin could work was generated, we have hit the next problem, the Plugin and the OAuth Authentication works, but after a user logs in, the IAM is only sending “sub” and “accountId” user attributes to the WordPress Server. The issue here is that the free version of the MiniOrange Plugin only supports “mail” attribute at this point, the support is working on a trial version which we could try out with IAM found in the AppDev Pack.

The screenshot above shows a working configuration of MiniOrange Plugin.

In the next step, we would like to display and make the data editable, in Drupal for example, based on the Access each individual user has. We will see how that goes, but now we are confident that we can make it happen.

Update

We got the authentication to work, Domino Users can log in, via IAM on the WordPress site! As mentioned we needed the Enterprise Version of the MiniOrange OAuth Plugin for WordPress.

Tips about Configuring IBM Connections to work with SPNEGO as Authentication Mechanism

Recently a customer asked me to review his Connections environment and implement SSO via SPNEGO. He started implementing it, but he couldn´t make to work, so he wanted me to pick up where he left it and make it work. I had a fair share of troubles to make it work and along the way I found some “typical” problems, so I thought I share these issues (and some other I had in the past) with you and hopefully save you some time.

Invest time in reading the Documentation about the Technology you plan to use

On the second thought invest a lot of time. The configuration will make sense only if you know the basics about Kerberos, SPNEGO and WebSphere Security in general. It will also help you a great deal troubleshooting and things like a WireShark trace (yes it may come all the way to that) will make much more sense. I strongly urge you to read the following article:

https://www.ibm.com/developerworks/websphere/library/techarticles/0809_lansche/0809_lansche.html

I never found a better article explaining how SPNEGO works in combination with WebSphere, it´s old, but it´s good.

I also recommend using the WebSphere documentation instead of Connections documentation (where it makes sense of course), I think that it is generally more in depth and more up to date. Which is OK I guess because Implementing SPNEGO has a lot more to do with WebSphere than with Connections Applications.

Plan Accordingly

Make sure your environment is up to date and there are no discrepancies between the Test and Production environment (a Test environment is essential). And keep it that way, I mean if you hit a “brick wall” in the Test Environment, do not go ahead and update the Production because a new Update came out. This will save you a lot of headache. Different versions mean different problems, so the chances are you will be trying to solve different problems in the Production than in the Test environment, when implementing SPNEGO, while the Production is down and someone is waiting for the whole thing to go online again.

Make sure Test and Production environments are the same

Here is where the details matter, I know that it is not always possible to have the exact same copy of a Production environment as a Test environment, but make sure that at least the things like DNS, Shares, User Access Rights… are the same as in Production. Difference between “CNAME” Alias and a “Host (A)” Record can have a lot of impact.

We had an issue, this will surely be a plague of the Test Environments, where the WebSphere Server Hostname, Primary Administration User and the URL for Connections Access, had a “Name-Clash” (as described in the URL pasted above) so make sure you check that and/or consider when building a Test environment.

Do it Step by Step

    I have made a mistake doing to many configuration changes at once, which essentially made it impossible to discover which part of the configuration led to an error. SPNEGO Implementation can be a combination of many different Configuration changes like: Primary Administrative User change, DNS changes and so on. So as my friend Martin Leyrer advised me, split the configuration in small steps/tasks, do one step, resync, restart and test and only after you are 100% happy with the change proceed with the next step.

Do you really need Kerberos?

As much as I know, SPNEGO is a “web friendly” version of Kerberos, right? So, it always made sense for me to do the Kerberos Configuration part in WebSphere before continuing with the SPNEGO part. Well I was wrong, the only Use-Case where you will need Kerberos implemented for IBM Connections is when you want to use IBM Connections Mail Plug-In with Exchange, which is not developed for Connections 6, so there´s that…

If you just want to achieve SSO from a Domain joined PC, then SPNEGO part will be sufficient. In that constellation Kerberos could just be another source of issues as Charlie Price made me realize that two months ago. 😀

LTPA Errors going through the roof

    We had an issue with LTPA, basically everything we tried to do in Connections GUI produced a mass of LTPA Errors in the logs. I tried everything, regenerating the LTPA Keys and so on, I contacted the support team, but we could not solve the issue. So, I asked Sharon Bellamy James for advice and she told me to export the LTPA Token from WebSphere and import it again, this solved that issue. The GUI looked much better and there were no LTPA Errors anymore.

Service Principal Name

When creating a Service Principal Name, never use “HTTPS/” in the “KTPASS” command, even though you are accessing Connections via “HTTPS”, only use “HTTP/”. For Examle:

ktpass -out c:\Node1.keytab –princ HTTP/connections.axians.local@AXIANS.LOCAL -mapuser connections_user -mapOp set –pass Password1 -ptype KRB5_NT_PRINCIPAL

If you need more than one keytab files and Service Principal Names, use a separate AD User for every one of them.

Delegation User Setting

    This is quite easy to forget, no matter what you do, Kerberos won´t work if your Service User Account used in the “KTPASS” command does not have the following setting set:

Although, I am not 100% sure you need to do this when you are Configuring SPNEGO without doing the Kerberos part in WebSphere. I will surely test this next time when I have a chance.

Disable TAI Authentication

    For SPNEGO to work with WebSphere as it should, you need to disable TAI Authentication:

Go to Security –> Global Security –> Custom Properties

Than enter the following:

Name

com.ibm.websphere.security.performTAIForUnprotectedURI

Value

false

 

I hope this is going to help someone, if you have any Tipps of your own, please share them in the comments below.