Some time ago, HCL Published a really cool “one-pager” document summarizing the most important features of HCL Nomad. I find this extremely useful, take a look how you can extend and improve your existing environment!
Make sure to register for the “How to Make Domino Deployment and Monitoring Radically Easier” Webinar taking place tomorrow at 3:00 PM – 4:00 PM CET.
Join this session to learn how to create a controlled, efficient Domino deployment (regardless of where you want your servers) powered by Panopta, our new partner. You’ll learn how to get complete visibility of your Domino servers’ key health metrics in easy to use dashboards, ensure the right person is notified in case of any health or performance issues, and solve problems with automated remediation instead of manual intervention. And, with much of the configuration done out of the box, you’ll learn how to get this all up and running quickly!How to Make Domino Deployment and Monitoring Radically Easier – Registration form
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.
As of now, there are no separate System Requirements listed for IAM component, of the Domino AppDev Pack, in the official documentation.
I opened a support case regarding this and got the information that the IAM component will run on any OS where the Node.js, version which is mentioned in the official documentation, will run.
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.