Claim Based Authorization

 

1.     Claim Based Authorization

·        Token Validation: As requests come into the Ocelot API Gateway, the first step is to validate the JWT token issued by FAMS. This validation checks the token's integrity and authenticity.

·        Fetch User Claims: Once the token is validated, Ocelot should then communicate with the admin microservice to retrieve specific claims related to the user's roles and permissions. This is crucial for implementing fine-grained access control based on the roles associated with the token's user.

 

·        Validate Token

o   custom middleware in Ocelot to intercept incoming requests. Extract the JWT token from the Authorization header. Validate the token’s signature, issuer, and expiration using FAMS's KID (Same as H2M  token validation strategy).

·        Retrieve User Claims

o   After successful token validation, extract the user identifier from the token (claim that identifies the user).

o   Make an API call from Ocelot to the admin microservice, passing the user identifier to fetch the corresponding roles and permissions.

o   The admin microservice should respond with the necessary claims which define what actions the user is authorized to perform.

·        Enforce Authorization

o   Utilize the fetched claims to enforce authorization policies within Ocelot. This can be done through route rules in Ocelot configuration.

o   Based on the claims, decide whether to forward the request to downstream services or reject it.

·        Caching

o   Caching roles and permissions in Ocelot if they do not change frequently, to reduce the number of requests to the admin microservice.

2.     Cross Zone Authorization

Users who are allowed to make a cross zone call will have a role defined in admin microservice (or in IAM).  That scope will be added to the authorization header which can then be used in make cross zone api call else reject in its own zone

For cross zone call, add custom claim Boolean flag indicating cross zone access.

·        Ocelot receives cross zone request with role, extracts the JWT token.

·        Forwards the token to authorization service.

·        Authorization service validates the token and check cross zone permission.

·        Authorization service will allow/deny the request.

 

Authentication in depth in Microservices architecture

I had posted an article on two tier authentication earlier.  Please read the post below for details

 https://vamsitokala.blogspot.com/2023/09/two-tier-authentication-in.html

I am adding some more insights on the Authentication  process in microservices architecture

1.     Angular Client (User) to Microservice Communication

For client-to-microservice interactions where the client is a angular web application with FAMS as IDP

 

·        Client Authenticates Directly with FAMS:

o   Angular UI initiates the authentication process with FAMS,  This involves redirecting the user to login page of IDP(intranet)

o   Upon Authentication, IDP issues an ID token, Access Token, Refresh token

·        Sending Requests to Microservices:

o   Client Sends Request with Access Token: When making requests to the microservices, the client includes this token in the Authorization header.

o   These requests are directed towards the API gateway ( Ocelot), which acts as the entry point to the microservices architecture.

 

·        API Gateway Validates Token:

o   The API gateway (Ocelot) intercepts the incoming request, validates the token (ensures it's valid, checks expiration, and verifies it against IDP JWKS endpoint), and if valid, forwards the request to the appropriate microservice.

o   Microservices themselves might not need to validate the token again and they trust the API gateway's authentication process.

·        Cache

o   Caching Public Keys: Cache FAMS’s JWKS end point at the api gateway to minimize network calls for key retrieval during token validation.

 

2.     Microservice to Microservice (Service-to-Service) Communication

For microservice-to-microservice communication that requires server-to-server authentication without user context:

·        Microservices Act as Clients to Cognito:

o   In this scenario, microservices acts as a "client" and uses the Client Credentials OAuth flow to authenticate with AWS Cognito and obtain an access token.

·        Obtaining a Token Before Reaching the API Gateway

o    A microservice that needs to make a request to another microservice through the API gateway first obtains a token from Cognito using its own credentials (client ID and secret).

·        Include the Token in API Calls:

o   This service then makes the API call through the API gateway, including the access token in the Authorization header.

·        API Gateway Validates the Token:

o   As with user-initiated requests, the API gateway validates the token before routing the request to the target microservice.

 

3.     Implementation Considerations

By centralizing authentication logic at the API gateway level, you can streamline security management and ensure consistent authentication across all services.

·        Secure Storage of Credentials

o   Services using the Client Credentials flow must securely store their AWS Cognito credentials (client ID and secret) in AWS secret manager.

·        Configuration in AWS Cognito

o   Create a User Pool - All Microservices are part of single eLIMS system sharing the same user base, A single user pool might be sufficient.

o   Configure each Microservice as an App Client in Cognito user pool

§  Enable OAUTH flow for each client for M2M

·        Token Validation

o   IDP (intranet) Token Validation

§  Validate token signature against JWKS endpoint for FAMS

·        Check

·        Token Expiration

·        Issuer (ISS)

·        Audience (aud)

o   Audience should match app client id

o   Cognito Token Validation

§  By setting AWSCognito:Authority, it automatically retrieves JWKS from AWS cognito and validates it implicitly

§  we want to disable audience validation. For example, if we have a microservices architecture where multiple APIs are using the same JWT for authentication, wemight set ValidateAudience to false to allow any of the APIs to accept the token.

§  In general, it’s recommended to keep ValidateAudience set to true to ensure the token is intended for the correct recipient. But the final decision depends on specific use case and security requirements.