wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Fun with Azure Active Directory & JWT


Active Directory has been the dominant standard for IT directories, even if it isn't the prettiest tree in the forrest. It's younger sibling ~~Azure Active Directory~~ Entra ID is a big player in cloud based Identity Providers (IdP). Unsurprisingly it behaves differently than the gold standard KeyCloak

JWT expectations

A Json Web Token (JWT) payload is a very losely definded JSON object with various claims. There is only a minimal consent of properties":

{
  "iss": "https://where-it-came-from",
  "audience": "https://where-it-should-be-valid",
  "iat": "DATE/TIME -> issued at",
  "exp": "DATE/TIME -> expiry",
  "scope": "space separated list of scopes",
  "email": "user's email"
}

The whole thing is (un)defined in RFC7519, sufficiently loose, so anyone can claim to be standard compliant and nothing is interoperable (just like ical). There is a list of known claims, but RFC7519 states: "None of the claims
defined below are intended to be mandatory to use or implement in all
cases, but rather they provide a starting point for a set of useful,
interoperable claims.
"

To ease validation of signatures, one can use an URL .../.well-known/openid-configuration which provides a number of needed properties:

  • various endpoint URLs for authentication and token exchange
  • issuer: The value corresponding to the iss property in a JWT
  • jwks_uri: URL to read the public key to validate signatures
  • scopes_supported: what scopes does the API support

Azure - same but different

When you setup Domino for JWT you need a series of specific conditions. The interesting parts from the documentation:

  • One of the JWT's "aud" (audience) claims must match the Domino Internet Site's host name
  • JWTs must contain a "iss" (issuer) claim matching the "issuer" returned from the OIDC provider's .well-known/openid-configuration endpoint
  • JWTs must contain a "scope" claim that includes "Domino.user.all"

When you follow KEEP's how to configure Azure AD you will find a set of pain points, in no specific order:

  • You can't remove claims you don't need
  • Azure AD will not issue a scope claim, but an scp claim
  • The aud claim is fixed to the "Application ID URI"
  • The iss claim in a token does not match the issuer property from well-known/openid-configuration
  • The jwks_uri URL does not return an alg property for the algorythm (nor did I find any way to request an Elliptic-curve signer)

So there's tons of fun to be had with Azure ~~Active Directory~~ Entra ID


Posted by on 29 August 2023 | Comments (4) | categories: JWT WebDevelopment

Comments

  1. posted by Rob Mason on Monday 20 November 2023 AD:

    Does this mean that Entra ID / Azure AD can't be used as an OIDC ID Provider for Domino? Are the pain points something that can be overcome?


  2. posted by Lyu dev on Saturday 13 January 2024 AD:

    Navigating the intricacies of Azure Entra ID for JWT seems like a unique challenge. How do you address the discrepancies in claims, especially considering the fixed values in aud and iss, and the absence of certain properties like alg in the jwks_uri URL? How do you find the overall experience of working with Azure Entra ID compared to other Identity Providers like KeyCloak?


  3. posted by Stephan Wissel on Tuesday 16 April 2024 AD:

    We fixed it. AzureAD works as Domino IdP, both classic and the REST API.


  4. posted by Resident Paranoid on Friday 26 April 2024 AD:

    Microsoft's providers definitely offer more of a challenge than providers like KeyCloak that actually follow the OIDC standard and have a comprehensible administrative interface.

    To that end, we published whitepapers describing how to configure Azure AD and ADFS against Domino for both HTTP Bearer authentication and "Web Login with OIDC" using 12.0.2 FP2 or better.

    The "What's New in 14.0" section of the doc includes links to those four whitepapers:
    https://help.hcltechsw.com/domino/14.0.0/admin/wn_oidcprovidersupport.html?scLang=en

    The 14.0 doc describes the improvements in configuration between 12.0.2 and 14.0: https://help.hcltechsw.com/domino/14.0.0/admin/secu_use_oidc_to_configure_federated_identity_auth.c.html