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.

Securing Intranet Applications: Bypassing Public API Gateway Limitations

 

In the realm of secure intranet applications, protecting sensitive data while ensuring easy access for authorized users is paramount. Traditional setups often rely on public API gateways, which can expose internal services to unnecessary risks. Here, we explore an innovative approach: using OpenResty as an external load balancer within a DMZ, integrated with a custom authentication system (FAMS). This architecture not only enhances security but also offers greater control over internal traffic management.

Why Move Away from Public API Gateways?

Public API gateways are designed for wide accessibility, which can be a double-edged sword for intranet applications. They expose endpoints to the public internet, increasing the attack surface. Furthermore, their generic nature might not align well with specific internal security protocols.

The OpenResty Advantage in a DMZ

OpenResty, an enhanced version of the Nginx web server, offers a powerful platform for building a more controlled and secure network architecture. Deployed as an external load balancer in a DMZ, it acts as a gatekeeper, ensuring only authorized traffic reaches the internal network. This setup significantly reduces exposure to external threats.

Key Benefits:

• Custom Traffic Management: Tailor traffic routing and load balancing to fit the unique needs of your intranet environment.
• Enhanced Security: With OpenResty in the DMZ, exposure to external threats is minimized, as it handles all incoming traffic and requests.
• Flexibility and Scalability: OpenResty's modular architecture allows for easy scalability and adaptability to changing security requirements.

Integrating FAMS for Authentication

FAMS, our custom authentication system, plays a critical role in this architecture. By integrating FAMS with OpenResty, we establish a robust authentication process for all incoming requests.

How it Works:

• Authentication at the Entry Point: OpenResty intercepts all incoming requests. It then leverages FAMS to authenticate and authorize these requests before allowing access to internal services.
• Seamless User Experience: Users interact with the intranet applications as usual, but with an added layer of security. The authentication process is transparent and efficient.

Overcoming Public API Gateway Limitations

This OpenResty and FAMS-based solution effectively addresses the limitations of public API gateways in several ways:

• Reduced Public Exposure: By situating the load balancing and authentication mechanisms in a DMZ, the internal network remains isolated from direct public access.
• Tailored Security: Unlike a one-size-fits-all public API gateway, this setup allows for customized security measures that align precisely with internal policies.
• Control Over Traffic: Direct control over routing and load balancing ensures that only legitimate, authenticated requests are processed.

Conclusion

For organizations seeking to bolster the security of their intranet applications, transitioning from a public API gateway to an OpenResty and FAMS-based architecture offers a compelling solution. This approach not only enhances security but also provides greater control and flexibility, ensuring that internal applications remain both accessible and protected.

Two-Tier Authentication in Microservices Architecture

 

Microservices are decoupled, self-contained units, which makes security pivotal. Two-tier authentication can offer an extra layer of protection. By integrating both AWS Cognito (for cloud-based authentication) and FAMS (an on-premises solution), we can create a robust authentication mechanism for such architectures.

It's a clear separation of concerns, with FAMS focusing on user identity and Cognito securing your API. This is a valid and robust approach, particularly if you want to leverage Cognito's capabilities for managing API access without intertwining it with FAMS.

Two-Tier Authentication in Microservices

Microservices often communicate through APIs. The two tiers in this setup are:

On-Premises Authentication (e.g., FAMS): Before accessing cloud-based microservices, authentication through on-prem systems like FAMS ensures that the initial user or service is validated.

Cloud-Based Authentication (e.g., AWS Cognito): After the initial validation, Cognito facilitates the subsequent authentication steps, providing tokens that are required to access microservices' endpoints.

Benefits of Using AWS Cognito with FAMS

·        Seamless Integration: AWS Cognito integrates well with AWS services and can work in tandem with FAMS for initial authentication.

·        Token-based security: After initial authentication with FAMS, Cognito handles token-based authentication for cloud resources.

·        Flexibility: Offers the ability to switch between different authentication providers.

Sequence Flow in a Microservices Environment

 

Conclusion

Two-tier authentication using both FAMS and AWS Cognito offers a comprehensive authentication strategy for microservices, bridging on-premises systems and cloud architectures. It ensures that microservices are only accessed by authenticated clients and services, upholding the principles of security and integrity.