The BSN.cloud Self API version 2022/06 now lets persons authenticated by external identity providers (MS Microsoft Entra ID), and using OAuth2 access and refresh tokens without a network context, sign in to a network.
The Keycloak intermediate identity and access manager (IAM) will replace has replaced the custom BSN.cloud Authentication Server authentication server (oa.bsn.cloud) for person registration, authentication, and password reset workflows. User access and refresh tokens will disappear along with all network-specific OAuth2 scope tokens and claims currently used by BSN.cloud API client applications. To provide equivalent functionality and .
BSN.cloud Self API will be extended, and BrightSign has introduced the concept of a “User Session”, to provide the same functionality and to allow existing BSN.cloud API versions to be used by new versions of the new client application versions for persons authenticated by external identity providers, BSN.cloud Self API will be extended and BrightSign has introduced the concept of a “User Session”.
As a pre-requisite to this task implementation KeyCloak must be configured to add the sid (Session ID) claim to all Person Access and Refresh Tokens issued by it. This sid claim value must be assigned in result of the “Authorization Code” and “Resource Owner Password Credentials” OAuth2 Grant Flows execution and kept during the Person Access and Refresh Tokens rotation during the “Refresh Token” Grant Flow execution. It is also decided to allow for the same Person to maintain multiple active Sessions but only one Refresh Token related to each of them.
The solution of this task must satisfy the following functional requirements defined in conversation with Client Team, WSS and PSS developers who interact with BSN.cloud API:
retrieve the list of Networks available to a Person authenticated via KeyCloak;
sign into any of the available Networks having the provided ID or Name;
switch between the available Networks in scope of the same Person Session;
retrieve the Network ID and Name a Person is possibly signed into in scope of the current Session;
retrieve the Authorization Scope Tokens, which must be identical to OAuth2 Scope Tokens granted by BSN.cloud as a part of existing solution, granted in scope of the current Session;
terminate the current Session on Person sign out.
Based on the fact that the session ID may be extracted from the Person Access Token, which must be provided in any protected BSN.cloud API method call, it was decided to keep it implicit for client applications. So in order to satisfy the listed functional requirements the following changes must be made in scope of this task:
...
. The following changes have been made:
(User Session) A
sid(session Id) claim will be added to all person access and refresh tokens issued by Keycloak. Thesidis extracted from the person access token and so will be implicit for client applications.(User Session) The same person can maintain multiple active sessions but can have only one refresh token related to each session.
(User Session) The caller authentication workflow in BSN.cloud API
...
has been modified and the person claims identity is now resolved based on person access tokens issued by Keycloak
(User Session) The request authorization workflow in BSN.cloud API has been modified and
...
the OAuth2
...
scope-based authorization has been replaced by the identical custom check based on
...
the authorization scope calculated in the same way
...
.
(BSN.cloud Self API) The updated client applications
...
can now retrieve the
...
person membership information using the existing
GET ~/2022/06/REST/Self/Networks/andGET ~/2022/06/REST/Self/Users/methods
...
in the BSN.cloud Self API
...
.