- Poking Around With JavaSapi
- Per-NSF-Scoped JWT Authorization With JavaSapi
- WebAuthn/Passkey Login With JavaSapi
In the spirit of not leaving well enough alone, I decided the other day to tinker a bit more with JavaSapi, the DSAPI peer tucked away undocumented in Domino. While I still maintain that this is too far from supported for even me to put into production, I think it's valuable to demonstrate the sort of thing that this capability - if made official - would make easy to implement.
I've talked about JWT a bit before, and it was in a similar context: I wanted to be able to access a third-party API that used JWT to handle authorization, so I wrote a basic library that could work with LS2J. While JWT isn't inherently tied to authorization like this, it's certainly where it's found a tremendous amount of purchase.
JWT has a couple neat characteristics, and the ones that come in handy most frequently are a) that you can enumerate specific "claims" in the token to restrict what the token allows the user to do and b) if you use a symmetric signature key, you can generate legal tokens on the client side without the server having to generate them. "b" there is optional, but makes JWT a handy way to do a quick shared secret between servers to allow for trusted authentication.
It's a larger topic than that, for sure, but that's the quick and dirty of it.
Mixing It With An NSF
Normally on Domino, you're either authenticated for the whole server or you're not. That's usually fine - if you want to have a restricted account, you can specifically grant it access to only a few NSFs. However, it's good to be able to go more fine-grained, restricting even powerful accounts to only do certain things in some contexts.
So I had the notion to take the JWT capability and mix it with JavaSapi to allow you to do just that. The idea is this:
- You make a file resource (hidden from the web) named "jwt.txt" that contains your per-NSF secret.
- A remote client makes a request with an
Authorizationheader in the form of
- The JavaSapi interceptor sees this, checks the target NSF, loads the secret, verifies it against the token, and authorizes the user if it's legal
As it turns out, this turned out to be actually not that difficult in practice at all.
The main core of the code is:
To read the JWT secret, I used IBM's NAPI:
And then, for the actual JWT handling, I use the auth0 java-jwt library:
And, with that in place, it works:
That text is coming from a LotusScript agent - as I mentioned in my original JavaSapi post, this authentication is trusted the same way DSAPI authentication is, and so all elements, classic or XPages, will treat the name as canon.
Because the token is based on the secret specifically from the NSF, using the same token against a different NSF (with no JWT secret or a different one) won't authenticate the user:
If we want to be fancy, we can call this scoped access.
This is the sort of thing that makes me want JavaSapi to be officially supported. Custom authentication and request filtering are much, much harder on Domino than on many other app servers, and JavaSapi dramatically reduces the friction.