Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Extend BSN.cloud Self API v202206 to provide the ability to sign in into a Network for Persons authenticated by external identity providers (MS Entra ID) and using OAuth2 Access+Refresh Tokens which don’t have a context of a Network.

After considering multiple options in scope of BCN-14292 - Getting issue details... STATUS it is decided to use KeyCloak as an intermediate identity and access manager (IAM) which will replace the custom BSN.cloud Authentication Server (oa.bsn.cloud) in Person registration, authentication and Password reset workflows. The consequence of that is disappearance of User Access and Refresh Tokens along with all Network-specific OAuth2 Scope Tokens and claims which the existing BSN.cloud API client applications depend on. So in order to provide an equivalent functionality and allow the existing BSN.cloud API versions to be used by the new client application versions on behalf of Persons authenticated by external identity providers it is decided to extend BSN.cloud Self API and introduce a 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:

  1. retrieve the list of Networks available to a Person authenticated via KeyCloak;

  2. sign into any of the available Networks having the provided ID or Name;

  3. switch between the available Networks in scope of the same Person Session;

  4. retrieve the Network ID and Name a Person is possibly signed into in scope of the current Session;

  5. 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;

  6. terminate the current Session on Person sign out.

Based on the fact that 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:

  1. modify the caller authentication workflow in BSN.cloud API and resolve Person Claims Identity based on Person Access Tokens issued by KeyCloak;

  2. modify the request authorization workflow in BSN.cloud API and replace the OAuth2 Scope-based authorization by the identical custom check based on Authorization Scope calculated in the same way;

    • in result of these changes the updated client applications will get the ability to retrieve the Person membership information using the existing GET ~/2022/06/REST/Self/Networks/ and GET ~/2022/06/REST/Self/Users/ methods of BSN.cloud Self API;

  • No labels