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