First of all, everything you will read in this post is already available on the AppDevPack documentation. Maybe not so explicit as I try to write this up here but with some common sense, these finings are obvious. What are we looking at ? Well, in the past months I had to deal with personalized access to HCL Domino Data through the AppDevPack. This means, our code will have to do CRUD Operations based on a Domino User and her effective ACL settings in the respective Applications.

In stand-alone use cases (or, Domino only environments), this can easily be achieved through IAM and Authorization Code Flow, in short, the user authenticates against IAM and explicitly allows the execution of the requested transactions.

In an integrated Single Sign On use case, this method has some shortcomings - currently, IAM offers no trust mechanisms whatsoever from other IDPs. This means in addition to logging into your SSO solution, the user needs to re-authenticate against IAM when accessing Domino data. Not ideal nor elegant. But there's a workaround for that - certificate based authentication. What's that ?

When you set up domino-db/proton, you already create technical users that run the code from your node.js/Java middleware by authenticating against Domino using an ssl certificate, stored as an internet certificate in the person document on your domino server. The scripts delivered with the AppDevPack generate the necessary CA infrastructure and Certs and KYR-Files for you. With that, you can roll out these certificates to all users of your domino-db relevant applications in the address books of your organization. You only have to make sure that your node.js/java middleware has access to these certs/keys and can determine the user who's posting a request. This needs to be validated of course - so if you use e.g Azure AD as your SSO solution, your node.js/java middleware needs to validate the calling user against AAD and determine an identifier for the Domino user to detect the right certificate/key combination to be used for a Domino transaction. With this mechanism, you can achieve an easy workaround for single sign on integration.

This raised another couple of questions - for Notes users, this works fine. What about external users in a 2nd address book ? No problem, the same rules apply. Connect the addressbook using directory assistance and deploy the internet certificates. In both scenarios, person records are all you need, with one caveat - if you app needs encryption on the Domino side, your users need a full Notes.ID in an ID-Vault to encrpyt/decrypt data correctly. The table below shows some aspects that I found interesting for me to decide what road to use when authenticated/personalized access in needed using the AppDevPack:

What do I mean by session handling ? Well, using OAUTH Access Tokens, you would need some sort of persistence layer in your middleware to store the users access token between requests. This usually requires session handling in your middleware which causes some new challenges like session lifetime management and persistence of session data. Not that big of a deal but anyhow - using certs based authentication, you can build stateless APIs in your middleware and still achieve personalized access to data. That's appealing to me. Also, I don't have to deal with access token lifecycles on top of my session lifecycles and the Domino ACL is still the single point of truth on what access level a certain user will have in my application.

For proton btw., there is no difference in both ways of accessing data. Every transaction in an SSL encrypted scenario requires a cert/key combination that gets validates with every call. It doesn't  make any difference in "stress" for proton if the cert/key combo is different for every request. This mechanism also happens in an IAM/OAUTH based request, when the application user uses the "act-as-user" feature based on an access token.

So what is the issue with certs based auth then ? Well, right now (and not for long anymore :-)), the certs management is a very manual process. While all the necessary scripts are there already, they are not even loosely coupled into a admin friendly interface. But we are working on that, so stay tuned ;-). Also - be aware that those certs/keys never ever should surface somewhere publicly as they allow password-less access to your Domino data ! The certs/keys should be held securely on your middleware or in a certificate store that hand back the needed certs to you application on a by-use basis. This is an overhead that is definitely needed from a security standpoint IMHO.

So long for today !