Security Architecture

Owned by ivan.neganov (Unlicensed)
Last updated: Nov 02, 2022 by oussama.zeaiter (Unlicensed)
3 min read

The following diagrams illustrate the current and envisioned security architecture of the application.

Current State

At present the Vessel Registry internal portal is implemented as a server-side Blazor web application, which authenticates users (Internal site).

  1. On first visit (the user does not have a valid token) users are redirected to AAD to acquire and ID token (OIDC).

  2. On Calls made to backend services, an access token is acquired from AAD.

    1. VRG can use the on-behalf flow to proxy calls to the backend services

    2. Or Access token can be acquired by the VRM to make a direct Web API call

An external version of Vessel Registry can be accessed anonymously and does not provide authentication.

Future State

When looking at a future state, we need to make several assumptions about Vessel Registry Internal site, or any portal for that matter that requires end user authentication:

  • The portal will be implemented as a Blazor web assembly-based SPA application.

  • API services will be protected (no anonymous access).

  • Users will authenticate using Azure AD.

  • A “double hop” scenario when one protected API service needs to call another such service over HTTP/REST will be avoided in favor of a message broker-based approach, and is not shown here.

Authentication Flow

  1. User makes a request to the Internal Vessel Registration site.

  2. Blazor web assembly acquires access token over OAuth 2.0 Authorization Flow, redirecting user to Azure Login page if required. The flow utilizes PKCE, as is required of modern SPA applications.

  3. The token is then sent by the Blazor web assembly to the API Gateway, as it is shielding the underlying API following BFF design pattern.

  4. API Gateway checks that the Bearer token is present and valid, returning 401 otherwise, and forwards the request to a destination service, ServiceRequestsService in this case taken as an example.

  5. The API service has to also validate the token, and optionally inspect role claims that it contains, if its methods require specific roles a user accessing them must have. These roles are configurable through App Registration for the ServiceRequestsService in Azure AD. Should the validation fail, it would return 403.

  6. The API service then accesses data storage using a DB access account (and does not flow through identity of the current user to the database).

  7. The results are returned back to the API Gateway, which then sends them to the web assembly, ending the flow.

Considerations for External Vessel Registry Site

When an anonymous user accesses the services used by the site then there are two options for implementing security:

  1. Implement fully anonymous API services. This would be similar to how current site is implemented, except there would be an added proxy layer in the form of an API Gateway.

  2. Implement anonymous access to API Gateway from the client, but have API Gateway acquire an access token following client credentials grant. In this scenario, API Gateway would act as a client consuming the API services.

One disadvantage of option #1 is that one needs to maintain an anonymous and a protected version of the same API. Availability of option #2 depends on features of the API Gateway, and other considerations such as simplicity of local development experience.

Conclusion

This page presents a vision of a potentially common authentication/authorization pattern for a microservice. Please expect it to be revised as the team evaluates these scenarios and experiments with using API Gateway and BFF pattern.