Entra ID user provisioning

This guide explains the code changes needed to integrate with Entra ID and provide Just-In-Time user provisioning when the user logs in.

Just-in-time

This technique creates the user in the local DB at the point of login. It allows a new user account to assume default permissions when logging in for the first time.

An alternative is to use SCIM provisioning.

SCIM provisioning

With this approach the IdP proactively notifies the various downstream applications of user changes.

Shortly after when a user is created or updated, the IdP contacts the application using its SCIM interface to effect the changes. Entra ID typically contacts the application once every 4 hours / 40mins???

Default configuration

JHipster v8 creates a ReactiveOAuth2UserService<OidcUserRequest, OidcUser> bean in SecurityConfiguration.java to deal with mapping the logged in user to an OidcUser.

Without this bean the default OidcReactiveOAuth2UserService will be instantiated in getOidcUserService() of class ServerHttpSecurity.

A default ReactiveAuthenticationManager configuration is created via the createDefault() method of class ServerHttpSecurity.

The implementation tries to intercept the behaviour of the OidcReactiveOAuth2UserService loadUser() functionality, so that we can either:

  • locate the user in the local DB and add any stored permissions to the authorities,

  • or create the user in the local DB and set the initial permissions as authorities.

This was done via a ReactiveOAuth2UserService<OidcUserRequest, OidcUser> bean created via method oidcUserService() in SecurityConfiguration.java.

Authentication process

Once an OAuth authentication flow is initiated, the following partial flow can be witessed;

  • …​

  • ReactiveOAuth2JITProvisioninguUserService.loadUser(userRequest)

    • userRequest is converted into an OidcUser instance via the OidcReactiveOAuth2UserService.loadUser(userRequest) delegate.

    • user.attributes now contains a list of ID Token claims, like sub, iss, idp, etc.

    • user.authorities now contains a list of authorities, like

      • OidcUserAuthority - Indicating that this was an OIDC flow

      • SCOPE_xxx - SimpleGrantAuthorities, indicating each of the scopes that was assigned.

    • 'user.idToken` now contains the full details of the ID Token, with all the original claims

    • user.userInfo now contains the curated list of claims.

  • the roles or groups are identified from the claims, and then those are also added to the authorities.