Forem: Afraz Khan

How to setup Corporate Identity Access at scale in AWS?

Afraz Khan — Fri, 13 Jun 2025 16:16:41 +0000

Imagine a large enterprise with thousands of employees spread across multiple cross-functional teams. Managing access to AWS applications in such an environment can quickly become tedious—especially if you're relying solely on IAM users, IAM roles, and IAM policies to provision access.

These traditional IAM resources come with inherent limitations, such as role count restrictions, policy size limits, and the impracticality of managing access on a per-user basis. This manual process not only consumes time but also becomes increasingly unsustainable as the organization scales.

This is where AWS IAM Identity Center (formerly AWS SSO) comes in. It simplifies access management by allowing administrators to integrate their existing identity provider (such as Microsoft Entra ID, Okta, or Cognito Userpool) and automatically synchronize users and groups. This enables access provisioning at scale while reducing the overhead of manual configuration.

More details on automatic provisioning can be found in the AWS documentation.

You can also create and manage users directly within IAM Identity Center, if you don’t have an external identity provider.

Federate Access to Your Applications

Once your user directory is set up in IAM Identity Center, you can grant application access to users directly from the console.

Application Access

There are two types of applications that can be integrated:

AWS-Managed Applications

These applications are native to AWS and are maintained by AWS itself. They provide access to AWS services and features, and administrators configure access through the relevant AWS service consoles. They apply access rules in there as well. Multiple AWS services support this integration natively.

More detailes > HERE

Custom Applications

These are third-party or in-house applications that are either hosted on AWS or outside of it but need to access AWS resources on behalf of users.

More details > HERE

Trusted Identity Propagation

Trusted Identity Propagation is a feature of IAM Identity Center that enables your custom applications to access AWS resources with fine-grained, user-based access control.

These AWS resources are typically part of AWS-managed applications, and Trusted Identity Propagation allows custom applications to securely interact with them on behalf of a user.

More details > HERE

S3 Access Grants Use Case

Trusted Identity Propagation is supported across several AWS services, but for this blog, we’ll walk through setting it up using S3 Access Grants.

Supported usecase > HERE

In this scenario, S3 Access Grants acts as the AWS-managed application, while we simulate a custom application that uses an Amazon Cognito User Pool as both the identity provider (IdP) and OAuth 2.0 authorization server.

This setup demonstrates how TIP enables your application to make fine-grained, user-context-aware access requests to Amazon S3 securely and at scale.

Caution: TIP only works with OAuth 2.0 applications

Setup Guide

Import the IdP into IAM Identity Center

You can also create users manually in IAM Identity Center.

Note: User attribute mapping is important. Ensure that
attribute values match across both systems-for example,
username(Cognito) == username(Identity Center).

See example of IAM Identity Center user in below figure.
Set Trust Relationship with the OAuth 2.0 Server

Set up your custom application's OAuth 2.0 authorization server as a Trusted Token Issuer.
Follow the guide HERE

I did set up a Cognito Userpool for that purpose.
Create custom application in Identity Center

Register your custom app in IAM Identity Center and attach the previously defined Trusted Token Issuer.
Follow the guide HERE
Set up Trusted Identity Propagation

Configure which AWS-managed applications (like S3 Access Grants) your custom application can access, and specify the users or groups that are authorized.
Learn more HERE

Custom application is grnated access to S3 Access grants (AWS-managed application) in below figure.
Set up S3 Access Grants

Now, configure the S3 Access Grant for a desired S3 location. This enables an AWS-managed application for S3 Access Grants.
Follow the guide HERE

S3 Access Grant sample

Now, the setup is complete, let’s move on to the execution part.

Before diving in, it’s important to understand the concept of Identity-Enhanced IAM Role Sessions, which is a key prerequisite for Trusted Identity Propagation.

Identity Enhanced IAM Role Sessions

Whenever a custom application needs to access an AWS service or resource, it follows these steps:

Fetch an Identity Token:
The application contacts IAM Identity Center to exchange its JWT(IdToken) for a new JWT(IdToken) via the CreateTokenWithIAM API. This token contains the identity context of the currently signed-in user.
Assume an IAM Role:
The application then assumes an IAM role using the AssumeRole API. It attaches the identity context along with the request.
Access AWS Resources:
Using the returned temporary AWS credentials, the application accesses the AWS resource (e.g., S3 via Access Grants).
Audit and Monitoring via CloudTrail:
The associated AWS service (like S3) logs the user identity context in CloudTrail.

Example below

This enables auditing, monitoring, and debugging based on the actual user's identity, not just the application's role.

The diagram below illustrates this flow clearly:

Trusted Identity Propagation(TIP) IN Action

As the custom application accesses AWS resources using Identity-Enhanced IAM role credentials, the target AWS service intercepts each request and validates access based on the attached user identity context.

In our case, S3 Access Grants evaluates the request against the authorization rules defined and either ALLOWS or DENIES access accordingly.

See GetDataAccess API

This is the core of Trusted Identity Propagation—ensuring that access control decisions are made based on the original user's identity, not just the permissions of the application role.

The diagram below illustrates the complete design:

Sample Notebook

I’ve implemented the flow in a Jupyter notebook, which you can find HERE. Feel free to fork it and set it up for your own experimentation.

If you encounter any issues during the setup, refer to the official documentation HERE

That’s all for now. I hope this blog helps you implement scalable access for your AWS applications. Happy learning! 😊

Implementing Single Sign-On (SSO) in Your Microsoft Teams Bot App [Part II]

Afraz Khan — Sun, 08 Sep 2024 20:39:41 +0000


1. Part I - Simple Teams Bot App Setup
2. Part II - Enable SSO for Teams Bot App

In the previous article, we explored the process of setting up a simple echo bot app in Teams. In this article, we will examine the Single Sign-On (SSO) options for enabling authentication in a Teams bot app.

Teams Bot App SSO

Teams apps are available in the Teams client either through the app store or via Admin-approved apps section "Build for your org". It means users must be logged into Teams before accessing the apps.

So by default, no additional login is required for users to access the app. However, if you want to enable authentication for your app, SSO is one of the options available. Users will be prompted to consent to the scopes defined by the app. Once consent is given, the user is granted access to the app.

Technically, a token is generated for each bot message request. This token can be used in the bot backend to make API calls to various Microsoft services (e.g., Skype, OneNote) on behalf of the user.

For more information, visit here.

Let’s dive into it.

SSO Setup

To configure SSO for your Teams bot app, you need to update three components:

Microsoft Entra ID App
Bot Registration in Azure Bot Service
Minor Updates in the Teams Developer Portal App

(We created all these resources in the previous article)

I won’t detail the configuration steps for these components here, as comprehensive guides are available from Microsoft on their official documentation platforms. You can refer to the following resources:

OAuth Dialog Flow

Once the initial setup is complete, it’s time to implement some code changes. You need to integrate an OAuth dialog flow into your existing bot app, which will enable the Bot Framework to handle the complete SSO authentication flow.

For each bot message received, this dialog flow is executed. Its responsibility is to fetch the token from the Bot Framework Token Service and make it available in the message context. For more details, please refer to the SSO architecture discussed in the first section of this article.

No User Consent

You can implement this OAuth dialog flow according to your use case. If you prefer not to have users provide explicit consent and only want to acquire the token directly, you should enable "Admin Consent" for all the scopes/permissions in the Microsoft Entra ID app.

If there is no Admin Consent then users are shown a consent screen everytime there is request for new token generation from the Bot Framework.

Code Changes for a Node.js Bot Backend

To integrate SSO into your existing bot app, you'll need to restructure and add some components to the Bot backend:

Inject SSO Middleware Integrate the SSO middleware into your bot to handle authentication flow.

const {TeamsSSOTokenExchangeMiddleware} = require('botbuilder');
const tokenExchangeMiddleware = new 
TeamsSSOTokenExchangeMiddleware(memoryStorage, env.connectionName);
adapter.use(tokenExchangeMiddleware);

Implement OAuth Dialog I’m pasting the smallest possible version of the dialog code below. Feel free to tweak it as needed.

// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.
const { ConfirmPrompt, DialogSet, DialogTurnStatus, OAuthPrompt, WaterfallDialog } = require('botbuilder-dialogs');
const { LogoutDialog } = require('./logoutDialog');
const CONFIRM_PROMPT = 'ConfirmPrompt';
const MAIN_DIALOG = 'MainDialog';
const MAIN_WATERFALL_DIALOG = 'MainWaterfallDialog';
const OAUTH_PROMPT = 'OAuthPrompt';
class MainDialog extends LogoutDialog {
    constructor(userState) {
        super(MAIN_DIALOG, process.env.OAuthConnectionName);
        this.addDialog(new OAuthPrompt(OAUTH_PROMPT, {
            connectionName: process.env.OAuthConnectionName,
            text: 'Please Sign In',
            title: 'Sign In',
            timeout: 300000
        }));
        this.addDialog(new ConfirmPrompt(CONFIRM_PROMPT));
        this.addDialog(new WaterfallDialog(MAIN_WATERFALL_DIALOG, [
            this.promptStep.bind(this),
            this.processTokenStep.bind(this)
        ]));
        this.initialDialogId = MAIN_WATERFALL_DIALOG;
        this.userState = userState;
        this.authTokenAccessor = this.userState.createProperty('AuthToken');
    }
    /**
     * The run method handles the incoming activity (in the form of a DialogContext) and passes it through the dialog system.
     * If no dialog is active, it will start the default dialog.
     * @param {*} dialogContext
     */
    async run(context, accessor) {
        const dialogSet = new DialogSet(accessor);
        dialogSet.add(this);
        const dialogContext = await dialogSet.createContext(context);
        const results = await dialogContext.continueDialog();
        if (results.status === DialogTurnStatus.empty) {
            await dialogContext.beginDialog(this.id);
        }
    }
    async promptStep(stepContext) {
        try {
            return await stepContext.beginDialog(OAUTH_PROMPT);
        } catch (err) {
            console.error(err);
        }
    }
    async processTokenStep(stepContext) {
        const tokenResponse = stepContext.result;
        if (!tokenResponse || !tokenResponse.token) {
            await stepContext.context.sendActivity('Authentication was not successful please try again.');
        } else {
            this.authTokenAccessor.set(stepContext.context, { token: tokenResponse.token });
        }
        return await stepContext.endDialog();
    }
}
module.exports.MainDialog = MainDialog;

Attach User State, Conversation State, and OAuth Dialog Configure your bot to use userState, conversationState, and the OAuth dialog to manage user interactions and authentication.

const {
    CloudAdapter,
    ConversationState,
    MemoryStorage,
    UserState,
    ConfigurationBotFrameworkAuthentication,
    TeamsSSOTokenExchangeMiddleware
} = require('botbuilder');
// Create conversation and user state with in-memory storage provider.
const conversationState = new ConversationState(memoryStorage);
const userState = new UserState(memoryStorage);
// Create the main dialog.
const dialog = new MainDialog();
// Create the bot that will handle incoming messages.
const bot = new TeamsBot(conversationState, userState, dialog);

Cache the Token Implement logic to save the token for future use. The recommended approach is to persist the token in the Bot user state cache. See the Dialog logic above. For more details on managing cache and state in the bot backend, refer to the official guide.
Access the Token in the Bot Once token is saved in the cache via th OAuth Dialog. Make changes in your Bot's onMessage endpoint to load it.

class DialogBot extends TeamsActivityHandler {
    constructor(conversationState, userState, dialog) {
        super();

        if (!conversationState) {
            throw new Error('[DialogBot]: Missing parameter. conversationState is required');
        }
        if (!userState) {
            throw new Error('[DialogBot]: Missing parameter. userState is required');
        }
        if (!dialog) {
            throw new Error('[DialogBot]: Missing parameter. dialog is required');
        }
        this.conversationState = conversationState;
        this.userState = userState;
        this.dialog = dialog;
        this.dialogState = this.conversationState.createProperty('DialogState');
        this.authTokenAccessor = this.userState.createProperty('AuthToken');

        // See https://aka.ms/about-bot-activity-message to learn more about the message and other activity types.
        this.onMessage(async (context, next) => {
            console.info('OnMessage: New message is received.');
            const processingMessage = await context.sendActivity('Processing your request...');

            // Dialog is executed
            await this.dialog.run(context, this.dialogState);

            // Load the token from the cache
            const authToken = await this.authTokenAccessor.get(context, {});
            console.log(`Token ==> ${ authToken }`);
            const memberData = await this.getTeamsMemberInfo(context);
            console.info(`OnMessage: member ==> "${ memberData.aadObjectId }".`);

            await context.updateActivity({
                id: processingMessage.id,
                type: 'message',
                text: 'Thanks'
            });
        // By calling next() you ensure that the next BotHandler is run.
            await next();
        });
    }
    /**
    * Override the ActivityHandler.run() method to save state changes after the bot logic completes.
    */
    async run(context) {
        await super.run(context);
        // Save any state changes. The load happened during the execution of the Dialog.
        await this.conversationState.saveChanges(context, false);
        await this.userState.saveChanges(context, false);
    }
    async getTeamsMemberInfo(context) {
        const response = await TeamsInfo.getMember(context, context.activity.from.id);
        return response;
    }
}
module.exports.DialogBot = DialogBot;

And you are done 😍. Now SSO is enabled for the bot app.

All of these changes are mentioned on the official documentation and also refer to the SSO sample. Again, You can play around with this sample as per your usecase.

Happy learning 🚀!!!


1. Part I - Simple Teams Bot App Setup
2. Part II - Enable SSO for Teams Bot App

Building a Microsoft Teams Bot App – Step-by-Step Setup Guide [Part I]

Afraz Khan — Sun, 08 Sep 2024 20:29:55 +0000


1. Part I - Simple Teams Bot App Setup
2. Part II - Enable SSO for Teams Bot App

Microsoft Teams is a powerful collaboration platform, and integrating a bot can streamline numerous tasks for your team. In this guide, I'll walk you through the process of setting up a Bot App in Microsoft Teams, covering everything from app registration to deployment.

Prerequisites

Buy subscriptions for MS365 and Azure.
Ensure you use the same tenant for Microsoft Teams and Azure.
Install the ngrok to setup an HTTP tunnel.
Install Nodejs18.x.
Follow the steps in the specified order to avoid issues during setup.

Step 1: Microsoft Entra ID App Registration

Register a New Application
- Go to the Microsoft Entra ID – App Registrations portal.
- Register a new application. Choose options that suit your use case.
- save the Application/Client ID for future use.
Create Client Secret
- Navigate to "Certificates and Secrets" and create a new client secret.
- Make sure to save the secret value immediately, as it is revealed only once.

Step 2: Setting up the Bot Backend Service

Teams Bots are developed using the Microsoft Bot Framework, a collection of tools and SDKs designed to build intelligent bots. To get started, you need to set up the backend service for the bot. (Bot registration is performed in the very next section)

Download the Echo Bot Sample
- Download a simple echo bot (written in nodejs) from the sample here. This bot just responds with the same user message as received.

Update Environment Variables

Update the environment variables in the .env file of the downloaded project:

  MicrosoftAppType={"MultiTenant" or "SingleTenant" based on                         the setting you selected while creating the app registration}
  MicrosoftAppId={App ID from previous step}
  MicrosoftAppPassword={App Password from previous step}
  MicrosoftAppTenantId={ignore if multi-tenant app else put the tenant-id}

Run the Backend
- Read the relevant README file to run the backend.
Set Up HTTP Tunnel
- Now, set up an HTTP tunnel at port 3978 via ngrok.

Step 3: Bot Registration in Azure Bot Service

Create a Bot Framework Registration Resource
- Go to the Azure Portal.
- Create a Bot Framework registration resource.
  - In the left panel, select Create a resource.
  - In the search box enter bot, then press Enter.
  - Select the Azure Bot card.
  - Select Create.
- Provide the necessary details such as project details, data residency, and app ID from the previous step.
Enable the Teams Channel
- Make sure to enable the Teams Channel in the bot settings.
Set Up Messaging Endpoint
- Configure the messaging endpoint with below Url format: https://{ngrok-domain}/api/messages

Step 4: App Registration in Teams Developer Portal

Create a New App
- Sign in to the Teams Developer Portal and create a new app.
- Fill in the required fields under the "Basic Information" section, including the MS Entra ID app ID.
Branding and Features
- Update the app icons under the "Branding" section.
- In "App Features," setup the Bot feature for the app. or link the Bot feature tile with the MS Entra ID app ID.
Allow Required Domains
- Navigate to "Domains" and allow the following domains:
  - *.ngrok-free.app
  - *.ngrok.io
  When setting up for production, be sure to allow the production service domain here once you're ready. Additionally, for successfull app auth, you need to allow other domains as well, such as token.botframework.com is mandatory.

Step 5: App Distribution

Validate the App
- In the Teams Developer Portal, navigate to your app.
- Use the App Validation section to check for any critical issues.
Publish the App
As per your requirements, you can publish the app to the App Store or your organization etc.
- For organization wide apps, publish the app to your organization via the "Publish to Org" section.
- Request your Teams Admin to approve and distribute the app within the organization.
Installation
- Once approved, the bot will be available for installation in the Teams client.

You may need to go through a rigorous approval process to publish the app to the store. For more information, refer to the documentation.

Sample Bot UI

ref ==> [1], [2]

Next, we will enable authentication for the app using Microsoft SSO.


1. Part I - Simple Teams Bot App Setup
2. Part II - Enable SSO for Teams Bot App

Whitelisting URL Paths Using Regular Expressions

Afraz Khan — Sun, 28 Apr 2024 00:27:58 +0000

In software development, there are times when you need to restrict the execution of certain blocks of code based on the incoming request URL. One common way to achieve this in a web application is by whitelisting specific URL paths using regular expressions (regex).

Why Use Regular Expressions?

By using regex, you can create a pattern that matches a set of URL paths that you want to allow or "whitelist". This approach provides flexibility and allows you to define complex matching criteria for your whitelisted paths.

Creating the Whitelist

To whitelist specific request paths, you'll need to create a regular expression for each path. Once you have all the individual regex patterns, you can merge them into a single regex pattern for better performance.

Here's an example demonstrating how to create a whitelist using a single regex pattern:

/**
 * Regular expression pattern for whitelisting request paths.
 * Each pattern represents an allowed HTTP method and path.
 */
const whiteListedPathsPattern = new RegExp(
  [
    `^GET /api/user$`,
    `^POST /api/app//products/search$`,
    `^POST /api/app/uninstall$`,
    `^POST /api/app/disconnect$`,
    `^GET /api/app/complaince/[a-z_]*$`,
    `^POST /api/notification/brand$`,
  ].join('|')
);

const incomingRequestUrl = 'URL_HERE';

if (whiteListedPathsPattern.test(incomingRequestUrl)) {
    // Execute your code block
    console.log('Request is whitelisted. Proceeding with the execution...');
} else {
    // Handle unauthorized request
    console.log('Request is not whitelisted. Access denied.');
}

Complete Express.js Example

For a comprehensive example demonstrating how to implement this in an Express.js application, check out this GitHub Gist.

Transforming TypeScript Enums into Object Arrays

Afraz Khan — Sat, 20 Jan 2024 14:41:03 +0000

Typescript enums are of three types:

Numeric enum:

All enum members have numeric values.
String enum:
All enum members have string values.
Heterogeneous enum:
Enum members are mixed but its essential for numeric members to follow a valid numeric value order.

In TypeScript, enums are compiled into JavaScript objects (here). As a result, native object methods Object.values() and Object.keys()can be used at runtime to construct an object array from an enum. However, please note that the process may differ for each enum type.

String enum

Its the most straight-forward enum type to constract arrays from. Utilize the Object.values() or Object.keys() method, depending on your specific requirements.

enum Scope {
    CREATE = "create",
    UPDATE = "edit",
    DELETE = "delete"
}

let Scopes = Object.values(Scope) as string[];
console.log(Scopes) // ["create", "edit", "delete"]

Scopes = Object.keys(Scope) as string[];
console.log(Scopes) // ["CREATE", "UPDATE", "DELETE"]

Numeric enum

As enums are compiled to objects, accessing the value of an enum member using its key is standard. However, with numeric enums, the reverse is also possible – you can access the enum member key/name using its value. This behavior is referred to as Reverse-Mapping. Read more

In essence, keys become values, and values become keys :). Consequently, the output array of both Object.values() and Object.keys() methods will have twice the number of elements compared to the original enum.

You have the flexibility to trim or transform the results according to your specific requirements. 👇

// Numeric enum starting from 2.
enum Scope {
    CREATE = 2,
    UPDATE,
    DELETE
}

let Scopes = Object.values(Scope) as string[];
console.log(Scopes) // ["CREATE", "UPDATE", "DELETE", 2, 3, 4] 

Scopes = Scopes.splice(0, (Scopes.length/2)) as string[]
console.log(Scopes) // ["CREATE", "UPDATE", "DELETE"]

Scopes = Object.keys(Scope) as string[];
console.log(Scopes) // ["2", "3", "4", "CREATE", "UPDATE", "DELETE"]

Scopes = Scopes.splice(0, (Scopes.length/2)) as string[]
console.log(Scopes) // ["2", "3", "4"]

Heterogeneous enum

There is no Reverse-Mapping available for string enums or string enum members in case of Heterogeneous enums.

Output of Object.keys() and Object.values() depends on the number of string and numeric members present in the enum.

// Heterogeneous enum with one string and three numeric members
enum Scope {
    CREATE,
    UPDATE = "edit",
    DELETE = 4,
    GET
}

let Scopes = Object.values(Scope) as string[];
console.log(Scopes) // ["CREATE", "DELETE", "GET", 0, "edit", 4, 5]

Scopes = Scopes.filter(scp => typeof scp === 'string' ) as string[]
console.log(Scopes) // ["CREATE", "DELETE", "GET", "edit"]

Scopes = Object.keys(Scope) as string[];
console.log(Scopes) // ["0", "4", "5", "CREATE", "UPDATE", "DELETE", "GET"]

Scopes = Scopes.filter(scp => Number.isInteger(Number(scp)) ) as string[]
console.log(Scopes) // ["0", "4", "5"]

Happy learning!! 💪

Elevating Code Flexibility: Dependency Inversion with DI Containers

Afraz Khan — Mon, 03 Jul 2023 12:05:02 +0000

Having tight-coupling between classes and objects is consistently detrimental, as it diminishes code flexibility and reusability. Each modification to a single component necessitates the vigorous task of dealing with its dependencies, causing developers to face recurring challenges.
In the realm of software development, the following design patterns serve as fundamental pillars extensively employed to eliminate tight coupling, especially when adhering to the SOLID principles.

Inversion-of-Control (IoC)
Dependency-Injection (DI)
Dependency-Inversion-Principle (DIP)

These patterns offer developers the means to decouple dependencies and achieve code that is flexible, maintainable, and extensible.

Furthermore, the modern landscape of development practices has witnessed the emergence of highly acclaimed "DI Containers" frameworks. These frameworks have revolutionized the implementation of IoC and DI, empowering developers to construct software architectures that are robust, modular, and scalable.

Lets review a practical example to employ the powerful Dependency Inversion Principle that results in modular and clean design. Examples are written for a TypeScript-based codebase utilizing InversifyJS as the DI Container.

Preliminary Setup

Lets expect that your application has a DI container set up, with each class appropriately attached to it using the necessary procedures. In InversifyJS, creating an application container is as straightforward as shown below:

`AppContainer.ts`

import {Container} from 'inversify';
import {ServiceOne, ServiceTwo} from '../services';

export class AppContainer {
  private static container: Container;

  public static build(){
    const container = new Container();

    container.bind<ServiceOne>('ServiceOne').to(ServiceOne);
    container.bind<ServiceTwo>('ServiceTwo').to(ServiceTwo);
  }
}

Practical Use Case

Lets take a fictional Authentication module in a codebase that solely relies on Google as the Identity Provider for managing authentication. However, a new requirement has emerged to incorporate Amazon as an additional Identity Provider.

👇 Current Code Structure

Imagine a service named Authenticator that primarily relies on Google as the identity provider, exemplified in the code snippet below.

`Authenticator.ts`

export class Authenticator {

  public initiateUserAuth(){
    // Google specific operations    
    .
  }

  public logoutUser(){
    // Google specific operations    
    .
  }
  .
  .
}

⭕ Tight Coupling found

In this scenario, the code exhibits tight coupling as the Authenticator service directly relies on the Google as the Identity Provider. To accommodate new Identity Providers, the code requires the introduction of if/else statements and as the number of Identity Providers grows, maintaining this code becomes increasingly complex and challenging. Now, it becomes evident that a significant restructuring is necessary to accommodate the integration of a new Identity Provider.

Looks like an exhastive task? 🙂

🍯 Desired Objective

The seamless integration of new Identity Providers should be accomplished without requiring any significant or even zero modifications to the Authenticator service.

🔍 Analysis

By leveraging the Dependency Inversion Principle, we can decouple the Authenticator service from the specific Google implementation. This involves introducing an abstract class or interface as a protocol for all Identity Providers to adhere to. Such decoupling ensures that changes or additions to low-level modules, like Google or Amazon Identity Provider, won't directly affect the high-level Authenticator module, promoting modularity and maintainability in the codebase.

Resolution

We require a substantial yet straightforward restructuring, outlined as follows:

Introduce a new module called IdentityProvider. Within this module,
- Create an interface named IIdentityProvider that encompasses essential methods and properties universally applicable to all Identity Providers in your system.
- Create an enum EIdentityProvider for the Identity Provider types.
IIdentityProvider.ts
```
export interface IIdentityProvider {
  fetchTokens(): string[],
  revokeTokens(): void
}

export enum EIdentityProvider {
  GOOGLE = 'GOOGLE',
  AMAZON = 'AMAZON'
}
```

Create a new GoogleIdentityProvider class which implements the IIdentityProvider interface.

`GoogleIdentityProvider.ts`

export class GoogleIdentityProvider implements IIdentityProvider{
    fetchTokens(): string[] {
       // google specific operations
    }
    revokeTokens(): void {
      // google specific operations
    }
}

Similar to GoogleIdentityProvider, Create a new AmazonIdentityProvider class.

`AmazonIdentityProvider.ts`

export class AmazonIdentityProvider implements IIdentityProvider{
    fetchTokens(): string[]{
      // Amazon specific operations
    }
    revokeTokens(): void{
      // Amazon specific operations
    }
}

Refactor the Authenticator class.

Introduce a new property called identityProvider, which stores the relevant Identity Provider instance based on the use case. Utilize this property to carry out the authentication process.

`Authenticator.ts`

import {inject} from 'inversify';

export class Authenticator {
  protected identityProvider: IIdentityProvider;

  constructor(identityProvider: IIdentityProvider) {
    this.identityProvider = identityProvider;
  }

  /* Authentication-related methods that are independent
     of any specific Identity Provider. */
  public initiaUserAuth(){
    .
    .
    return this.identityProvider.fetchTokens();
  }

  public logoutUser(){
    .
    .
    return this.identityProvider.revokeTokens();
  }
  .
  .
  .
}

Configure multiple instances of the Authenticator class in the DI Container. Each instance is initialized using a specific IdentityProvider type. To accomplish this, we will leverage the service identification methods offered by your DI Container framework.

See InversifyJS example below.

`AppContainer.ts`

import {Container} from 'inversify';
import {Authenticator, GoogleIdentityProvider, AmazonIdentityProvider, IdentityProvider} from '../services';

export class AppContainer {
  private static container: Container;

  public static build(){
    const container = new Container();

    /* Initialize an instance of each Identity Provider 
       class. */
    container.bind<GoogleIdentityProvider('GoogleIdentityProvider')
      .to(GoogleIdentityProvider);
    container.bind<AmazonIdentityProvider>('AmazonIdentityProvider')
      .to(AmazonIdentityProvider);

    /* Initialize multiple Authenticator instances based on 
       each Identity Provider type. */
    container.bind<Authenticator>('Authenticator')
      .toDynamicValue(context => {
        return new Authenticator(context.container.get('GoogleIdentityProvider');
      })
      .whenTargetTagged('IdentityProvider', EIdentityProvider.GOOGLE);
    container.bind<Authenticator>('Authenticator')
      .toDynamicValue(context => {
        return new Authenticator(context.container.get('AmazonIdentityProvider);
      })
      .whenTargetTagged('IdentityProvider', EIdentityProvider.AMAZON);
  }
}

Refactor the code, specifically in the sections where you want to load the suitable Authenticator instance based on the required Identity Provider type in the use case.

Take a look at the provided InversifyJS examples in a hypothetical Authentication Controller scenario.

`AuthController.ts`

import {AppContainer} from '../AppContainer.ts';
import {Authenticator} from '../Authenticator.ts';

export class AuthController{
  protected authenticator: Authenticator;

  @Post('/auth/google')
  public async initiateGoogleAuth(){

    // Loading Authenticator instance with GOOGLE Identity Provider
    this.authenticator = AppContainer.getTagged(
        'Authenticator',
        'IdentityProvider',
        EIdentityProvider.GOOGLE
    );
    .
    .
    .
  }

  @Post('/auth/amazon')
  public async initiateAmazonAuth(){

    // Loading Authenticator instance with AMAZON Identity Provider
    this.authenticator = AppContainer.getTagged(
        'Authenticator',
        'IdentityProvider',
        EIdentityProvider.AMAZON
    );
    .
    .
    .
  }
}

Default Implementation with Decorator Pattern

If 📜default behavior is necessary for your Identity Providers, considering an abstract class instead of an interface is a viable option. Moreover, if that default behavior serves as a valid form of an identity provider, it may be appropriate for the class to be concrete.
Other specific Identity Providers can inherit from this class, allowing them to modify or override the functionality as required. This particular scenario is a great application of the Decorator Pattern.

Create a component Interface.
Create a default-identity-provider/component class which implements component interface.
Create decorator/specific-identity-provider classes that inherit from the component class.

A good Decorator Pattern example here.

I hope, this helped you:), happy learning🚀

refs 1, 2

Reuse Redis Connections across AWS Lambda invocations

Afraz Khan — Mon, 24 Apr 2023 13:35:39 +0000

If you are familiar with the lambda execution environment and how it works for a single lambda function invocation, then it's a great opportunity for you to optimise your application's performance. The lambda execution environment enables you to persist and reuse DB connections, especially in situations where latency must be taken into account and connection open/close at the same time is not desirable.
👉 Lambda Execution Environment

Recently, I have implemented a solution for reusing Redis client connections across the invocations of a lambda function in a single lambda execution environment, I will share that here today.

Note that examples are given using TypeScript and
this blog could even help you to reuse your database connections (MySQL, PostgreSQL, etc.).

1. Make use of Lambda Static Initialization

The code placed outside of function's main handler method is run only when execution environment is spinned up for the first time. Lambda keeps that code as long as environment is warm.
👉 Static Initialization

Initialize a global variable outside the handler method that saves the Redis client object.

You can put this global Redis client variable in any file as per your function's code structure. Its not necessary to keep it in the handler method file.

2. Setup Idle Connection Timeout in Redis/database

Since, we want to reuse the database connections so, no need to end newly created connections.

Hence, delete the connection-close logic from your lambda function. If you have multiple usecases in your lambda function then do it only for those where you want to reuse the existing connection.

Note that, once a lambda execution environemnt is taken down, these opened connections become useless and they can take up as much memory to cause OUT OF MEMORY errors in Redis/database server.

Configure an idle connection timeout in Redis.(or in your database service) to terminate these idle connections automatically.

👉 Redis Client Handling

You need to be careful here, analyse your application requirements and configure a timeout in Redis as per your need.

It shouldn't be larger than the lambda execution environment idle timeout which lies somewhere between 40-50mins. I found this stat online but there's no proper evidence about it. You may wanna perform tests to find it yourself :)
Also, it shouldn't be very small at the same time, otherwise, your lambda function might create new connections as frequently as it matches the previous rate and this whole effort becomes pointless.

3. Update Redis Client Creation Logic

You need to update the client creation logic based on two things:

If existing client is active and working then function uses that instead of creating a new one.
Client would be reset if existing connection is terminated by Redis/database engine in the wake of connection idle timeout.

There are multiple ways to manage it:

Create a separate method called getRedisClient() as shown in the below figure. Keep the client reuse/reset logic in that method and only use it throughout the lambda function for fetching an active Redis client. This approach is cleaner and maintainable. If your application can bear the extra ping() call, then it is a good solution.
Here, move the client reset logic into the API methods like below. It saves you the ping() call, so it is more performant. This approach is favorable when your lambda function is doing only one task. If you have multiple business logic operations in your function, then maybe not a good option. You will have to insert the client reset logic in all those methods where Redis operations are performed. Not good for clean code principles.
Implement a Global Error Handler in the lambda function or a pattern like that. See if lambda retry mechanism helps for that. Basiaclly, idea is to transmit all errors to that error handler where the Redis/database client is reset as done in the second approach.

This looks like a perfect solution that avoids the extra ping() call in the first approach and the repetition pattern in the second approach.

I chose the first approach as it suited my application. The third option is just an idea that I didn't experiment with cz I am busy with other things🥲. Maybe you can give it a try and let me know :)

After updating the Redis client creation logic, your lambda funtions are all set🚀 to reuse the existing connections.

Cross-Account Deployment with AWS SAM

Afraz Khan — Wed, 29 Mar 2023 22:43:34 +0000

AWS SAM is a serverless framework that allows you to easily develop and deploy serverless applications in AWS environments.
Today, I will describe a couple of methods to execute cross-account SAM deployments that I have recently come across.
When we talk about multi-account deployment, we typically mean that your team has a central AWS account for devops-related activities, such as all of your CI/CD (Continuous Integration and Continuous Deployment) pipelines, which are in charge of deploying infrastructure and code changes to each application environment as the pull requests are merged.

Problem

There is a SAM project in your codebase that has some lambda functions to run. Requirement is to deploy this SAM project in the application account (lets call it Dev-Account) but via the devops account (lets call it DevOps-Account)

Resolution

In Dev-Account, deploy below resources:

We need to use a cross-account IAM role in the Dev-Account that will be assumed by DevOps-Account for carrying out the needed deployment actions.
- Put all permissions that DevOps-Account needs to execute the deployment in Dev-Account.
- Put the DevOps-Account in the trust-relationship of this role.

(Trust entity would look like below)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{DevOpsAccountID}:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

In DevOps-Account, deploy below resources:

An AWS CodePipeline pipeline which has at-least 2 stages. Let's call them Source and Deploy. You can add more stages as per your need) (https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html)
An S3 bucket where CodePipeline stores the artifacts coming from different stages/actions of the pipeline. (You can place this bucket either in Dev-Account or DevOps-Account, just update the policy accordingly)
A Customer-Managed KMS key in the DevOps-Account that is used by CodePipeline to encrypt/decrypt the objects in the artifacts bucket.
The Deploy Action in the CodePipeline must invoke a CodeBuild project.(read more about it in below section) This project is essentially responsible to building and deploying our SAM application. (sam build, sam deploy commands).

Each CodeBuild build is supposed to obtain the buildspec file from the pipeline stage input artifacts.

CodeBuild Project Location

Now, we need to decide about the location of the CodeBuild project

Integration tools, such as Codebuild, are typically stored in the devops/operations account alongside pipelines, but they can be moved to your application account as well. This is where the solution design can take several forms, and you must decide which one is best for you.

1. CodeBuild project placed in Dev-Account

I designed this solution myself, without online assistance like AWS forums or other platforms. Maybe you have already seen things like this, but it works.

Spin-up a CodeBuild project in the Dev-Account.
Create an IAM service role for CodeBuild in the Dev-Account. Provide the necessary permissions to this role, like CodePipeline artifacts bucket permissions, DevOps-Account KMS key permissions, CloudFormation permissions for SAM, and others as required.

(Find sample policy below)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:Encrypt",
                "kms:DescribeKey",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*"
            ],
            "Resource": [
                "{DevOpsAccountKMSKeyArn}",
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "cloudformation:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:Put*"
                "s3:ListBucket",
            ],
            "Resource": "{ArtifactsBucketArn}/*"
        }
    ]
}

Ensure that the artifacts bucket policy and DevOps-Account KMS Key Policy have access permissions for the Dev-Account CodeBuild service role.

Create an IAM service role for CodePipeline in DevOps-Account that has CodePipeline service in the trust-relationship and sts:AssumeRole permission to assume the cross-account role in Dev-Account.
- It must have permission to invoke the CodeBuild project in the Dev-Account.

(Find the sample policy below)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "{CrossAccountRoleArn in DevAccount}"
            ],
            "Effect": "Allow",
            "Sid": "CrossAccountAssumeRolePolicy"
        },
        {
            "Action": [
                "codestar-connections:UseConnection"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "AllowCodeStarConnection"
        },
        {
            "Action": [
                "codebuild:StartBuild",
                "codebuild:BatchGetBuilds",
                "codebuild:BatchGetBuildBatches",
                "codebuild:StartBuildBatch"
            ],
            "Resource": [
                "arn:aws:codebuild:{Region}:{DevAccountId}:project/*"
            ],
            "Effect": "Allow",
            "Sid": "CodeBuildPolicy"
        },
        {
            "Action": [
                "kms:DescribeKey",
                "kms:GetKeyPolicy",
                "kms:List*",
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:Generate*"
            ],
            "Resource": "{CustomerManagedKeyArn in DevOps Account}",
            "Effect": "Allow",
            "Sid": "KMSPolicy"
        }
        {
            "Action": [
                "s3:*"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "S3Policy"
        },
        {
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow",
            "Sid": "PassRolePolicy"
        }
    ]
}

Assign the Dev-Account cross-account IAM role to the Deploy stage action of the pipeline.

2. CodeBuild project placed in DevOps-Account

I guess this is the most effective approach, at-least for me :) because I want all my CD/CD resources to be in one place. It makes the management and tracking of resources easier.

Create the CodeBuild project in the DevOps-Account.

No need to assign any IAM role to the Deploy stage action in the pipeline because the CodeBuild project is in the DevOps-Account and the action will inherit the CodeBuild permissions from the parent pipeline service role.

Create an IAM service role for CodeBuild in the DevOps-Account that has CodeBuild service in the trust-relationship and sts:AssumeRole permission to assume the cross-account role in Dev-Account.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "{CrossAccountRoleArn in DevAccount}"
            ],
            "Effect": "Allow",
            "Sid": "CrossAccountAssumeRolePolicy"
        },
        .
        .
        .
        .
        .

    ]
}

Since, CodeBuild project is in the DevOps-Account, so SAM commands will deploy the resources in the DevOps-Account that is not correct. So, we need to set the Dev-Account credentials in the CodeBuild project in order for it to deploy the resources into the Dev-Account.
- Use the AWS Security-Token-Service to get the temporary credentials for the Dev-Account.

(Update your buildspec file like below)

version: 0.2

phases:
  build:
    commands:
      - echo getting AWS credentials for "$CROSSACCOUNT_SAM_ROLE"
      - |
        CREDENTIAL=$(aws sts assume-role \
          --duration-seconds 900
          --role-arn "$CROSSACCOUNT_SAM_ROLE" \
          --role-session-name SAMSession \
          --output text \
          --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken,Expiration]')
      - export AWS_ACCESS_KEY_ID=$(echo $CREDENTIAL | awk '{print $1}')
      - export AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIAL | awk '{print $2}')
      - export AWS_SESSION_TOKEN=$(echo $CREDENTIAL | awk '{print $3}')
      - export SESSION_EXPIRATION=$(echo $CREDENTIAL | awk '{print $4}')
- sam build      
- sam deploy --no-confirm-changeset --no-fail-on-empty-changeset

$CROSSACCOUNT_SAM_ROLE environment variable in above buildspec file refers to the cross-account Dev-Account IAM role.

Make sure that, cross-account IAM role has all necessary permissions needed to deploy the SAM resources.

SAM --role-arn arg

You might think that, there must be a way for the SAM to assume the cross-account IAM role in Dev-Account instead of generating the credentials explicitly. It would be a more cool🧊 solution, ain't it?

I tried that myself, there's a parameter in the SAM deploy command named --role-arn which basically CloudFormation service assumes to deploy the resources/changes.

(My buildspec was simple as below)

version: 0.2

phases:
  build:
    commands:
      - sam build
      - sam deploy --no-confirm-changeset --no-fail-on-empty-changeset --role-arn {CrossAccountDevRoleArn}

This results into below error

Cross-account pass role is not allowed (Service: AmazonCloudFormation; Status Code: 403; Error Code: AccessDenied; Request ID: d880bdd7-fe3f-11e7-8a8c-7dcffeae19ae)

Here, CodeBuild in DevOps-Account tries to pass a cross-account IAM role to the CloudFormation service in the Dev-Account and this is not possible.

You cannot use the PassRole permission to pass a cross-account role. read here

So, this hack wouldn't work🙂 and generating the cross-account credentials explicitly is the only solution as per my knowledge or that I could find online.

happy learning🚀

ref -> 1, 2, 3

Merge TypeScript Enums

Afraz Khan — Sun, 18 Sep 2022 11:33:41 +0000

There is no native support for merging 2 or more enums in typescript but its possible with a combination of type aliases and enums.

Merge Enums

Let suppose, you have 2 string based enums:

// enum 1
enum ManagedUserStatus {
  M_STATUS1 = 'M_STATUS1',
  M_STATUS2 = 'M_STATUS2',
  M_STATUS3 = 'M_STATUS3',
}

// enum 2
enum SystemUserStatus {
  Sys_STATUS1 = 'Sys_STATUS1',
  Sys_STATUS2 = 'Sys_STATUS2',
  Sys_STATUS3 = 'Sys_STATUS3',
}

Convert the enums into a single javascript object, lets call it enum object. Utilize the enum object in your codebase as a regular enum. This object has the union of all enums combined.

// same enum like values
export const UserStatuses = { ...ManagedUserStatus,
 ...SystemUserStatus }

// OR

// Kind of nested enum approach
export const UserStatuses = { ManagedUserStatus,
 SystemUserStatus }

Create a type from the enum object. Use this type as the regular enum type in your codebase.

Name of this type alias can be same as the enum object or anything else.

// 1. export as an object type
export type UserStatus = typeof UserStatuses;

// OR

// 2. export only the keys
export type UserStatus = keyof typeof UserStatuses;

// OR

// 3. export as a uinon type
export type UserStatus = ManagedUserStatus | SystemUserStatus;

This way, you can merge 2 or more enums and simulate the same enum like behavior in your codebase.

Sample usage

Lets imagine a method in your code which utilizes our newly created enum.

function confirmUser(status: UserStatus){
    if(status === UserStatuses.M_STATUS2){
        return false;
    }
}

Merge Issues

There are some limitations and issues with this kind of merge and you have to be aware of them before merging your enums.

Numbered Enums

With numbered enums, you will have duplicate values in the enum object.

enum ManagedUserStatus {
  M_STATUS1,    // 0
  M_STATUS2,    // 1
  M_STATUS3     // 2
}

// enum 2
enum SystemUserStatus {
  Sys_STATUS1,  // 0
  Sys_STATUS2,  // 1
  Sys_STATUS3   // 2
}

const UserStatuses = { ...ManagedUserStatus,
...SystemUserStatus };

type UserStatuses = typeof UserStatuses;

Make sure that, if you need unique values then assign proper initializers to your enums like below:

enum ManagedUserStatus {
  M_STATUS1,    // 0
  M_STATUS2,    // 1
  M_STATUS3     // 2
}

// enum 2
enum SystemUserStatus {
  Sys_STATUS1 = 6,  // 6
  Sys_STATUS2,      // 7
  Sys_STATUS3       // 8
}

Duplicate Keys

If your enums have duplicate keys then that key in the final enum object has over-written value. See below exmple

enum ManagedUserStatus {
  M_STATUS1,    // 0
  M_STATUS2,    // 1
  M_STATUS3     // 2
}

// enum 2
enum SystemUserStatus {
  Sys_STATUS1,  // 0
  M_STATUS2 = 'CONFIRMED',
  Sys_STATUS3 = 'UNCONFIRMED'
}

const UserStatuses = { ...ManagedUserStatus, 
...SystemUserStatus };

type UserStatuses = typeof UserStatuses;

const m_status2_value = UserStatuses.M_STATUS2; //  'CONFIRMED'

Nested Enums

If you plan to use the nested enums for the enum object then maybe you can ignore above issues because there is no actual merging process in that case. only key based enums are exported out of the enum object. See below

enum ManagedUserStatus {
  M_STATUS1,    // 0
  M_STATUS2,    // 1
  M_STATUS3     // 2
}

// enum 2
enum SystemUserStatus {
  Sys_STATUS1,  // 0
  M_STATUS2 = 'CONFIRMED',
  Sys_STATUS3 = 'UNCONFIRMED'
}

const UserStatuses = { ManagedUserStatus, 
SystemUserStatus };

type UserStatuses = typeof UserStatuses;

// no effect of duplicate keys
const mStatus2_one = UserStatuses.ManagedUserStatus. M_STATUS2; //  '1'
const mStatus2_two = UserStatuses.SystemUserStatus. M_STATUS2; //  'CONFIRMED'

// no effect of numbered values
const sysStatus1 = UserStatuses.SystemUserStatus. Sys_STATUS1; //  '0'

happy learning! 👊

AWS Cognito JWT Verification

Afraz Khan — Sat, 19 Feb 2022 23:24:27 +0000

AWS Cognito usually responds with 3 JWTs (IDToken, AccessToken, RefreshToken) for each successful login request. There is a fair chance that your application would use these tokens to

secure API requests.
manage permissions/roles based authorization to the resources.

& other custom authorization requirements.
Usually, IDToken & AccessToken are verified for such purposes, but not RefreshToken. It is there just to refresh the session.

Both IDToken & AccessToken have some common as well as unique claims so its 100% your own choice to decide where to verify which token according to your use-case.

Refresh Tokens

Afraz Khan — Sat, 01 Jan 2022 23:20:38 +0000

In OAuth implementation, Authorization/Resource server assigns an AccessToken to each successfull user session. AccessToken is used by the client to make requests to the resource server.

RefreshToken is issued to the client by the authorization server to obtain a new AccessToken when the current AccessToken becomes invalid or expires or to obtain additional AccessTokens with an identical or narrower scope. Basically, RefreshToken provides the clients with a smooth experience where users are not required to repeat login step or some other authentication flow in order to get new AccessToken.

References
IETF
oauth.net
oauth0.com

How to use Refresh-Token?

After each successfull authentication request, Authorization/Resource server must generate 2 JWT tokens (AccessToken , RefreshToken).

I talk here with JWT specification under consideration but tokens can be either JWTs or some other format of your choice. Its an implementation decision and not a topic to emphasize-on in this post.
Client will save both of the JWT tokens in the browser at some safe place.
RefreshToken JWT would have longer expiry (maybe 1 day) than AccessToken(could be 1-3 hours).
When AccessToken expires, the webapp/client would hit /api/auth/token endpoint with RefreshToken in request payload.

/api/auth/token is supposed to issue new AccessTokens.
Client does this silently without alerting the user.
The system will verify the RefreshToken and issue a new AccessToken without any user interaction involved.

RefreshToken Revocation

RefreshToken JWTs usually remain valid for longer durations like 1 day, 1 week or so and there is a chance that token could be compromised and misused beyond the user logout action if unexpired. To mitigate this potential threat, there should be some mechanism in place to invalidate the revoked but unexpired JWTs.

Some techniques are mentioned below:

JWT Whitelist

Here, the system maintains a whitelist of active RefreshTokens in some in-memory cache or database.

Every time a new RefreshToken request comes, the system looks for incoming RefreshToken in the in-memory cache or database.
If found, the system issues a new AccessToken else invalidates the request.

references: 1, 2, 3

JWT Blacklist

Here, the system maintains a blacklist of old/revoked refresh tokens in some in-memory cache or database. Revoked Tokens live on the blacklist until their expiry time is reached.

Every time a new refresh token request comes, the system looks for incoming RefreshToken in the in-memory cache or database.
If found, that means, the incoming RefreshToken is revoked and the system invalidates the request.

references: 1, 2, 3

Unique Claims

Every JWT has a claims list with it that includes information provided by user (email, name) as well as some attributes required by JWT Specification (iat, sub).
You can use any claim out of the JWT specification list to ensure token's authenticity. Use below technique:

Choose a token claim that is always unique at the time of token issuance.

JWT iat is best option as its a unix time stamp.
Introduce a new field in your User database table where system will save the value of that claim for each new RefreshToken that system generates for each login request.
When system recieves a request to refresh the AccessToken. System will verify if iat value of incoming RefreshToken matches the current iat against the current user in the database.
If both iat values match then system issues new pair of AccessToken and RefreshToken otherwise 401 throws exception.

Some Stateless techniques

In the above 2 methods, database queries are involved to check the JWT revocation and this makes the token stateful. But depending on the severity of the JWT compromise that one foresees, there are many techniques out there to avoid any unwanted activity using stateless JWTs.
2 of them described below:

Short Expiry times
The straightforward stateless solution enforces the use of short expiry times for both AccessToken and RefreshToken like 10min expiry for AccessToken and 1hr expiry for RefreshToken. This simply reduces the time for any malicious activity if occurred.
User-Defined Secret
For each user, use a different secret to sign the RefreshToken JWT like secret = ENV.secret + user.password while generating the RefreshToken. At any time, if RefreshToken of a particular user is compromised, ask that user to reset their password and all old RefreshTokens issued to that user would be revoked automatically.
See implementation: here

I hope this helps 🙂.

Python WSGI Applications

Afraz Khan — Mon, 18 Oct 2021 09:49:49 +0000

Http requests in python web applications are served as shown below

Web developers usually work with the web frameworks like Django, flask, but they hardly know the actual mechanics in place about how http requests float through the system and how the desired http response is generated.
A web framework is a major component of the whole process. These days, applications are written mostly under the web frameworks, but as a developer, its very essential to have the knowledge of each component of the request -> resposne cycle and in python web apps, WSGI is very important concept that you will learn in this post.

Some History

Before moving to WSGI details, I find that short look of history would be vital so lets start from when the web came into being.

Web or HTTP is static, by design this means it can only return you a static file on the server. Let's say, a web server receives a request as shown in below image GET /index.html. The server finds that page on the disk, reads index.html file and returns a response with content of index.html file. Web could also return CSS files or other static assets, but the whole idea back then was simple like this.

External Scripts

By early 90's, it was identified that the web was not an efficient and interactive way to entertain the dynamic http requests where each request doesn't have to update static html pages every time. Some dynamic method was needed to process inputs like html forms, sessions.

That was achieved by running external scripts that would process those new input types, i.e. html-forms, json(later).

At that time, external scripts were written in PERL or PHP, but it was doable with python also. External scripts were named after the input they used to process like form.py, json.py. form.py would process form-data and json.py would process json-data. Now, instead of sending bear metal file names in requests like GET /index.html. Web servers started to get requests as GET form.py. That used to indicate that server has to run form.py that is an external script to process an html form request.
Web server used to fork the parent process and run the scripts. Any print() statement in external scripts turned out to be the http response to the client.

CGI (Common Gateway Interface)

Web servers usually parse a http request, create some new environment variables and external scripts inherit them in the arguments. But different web servers named randomly to those environment variables that caused conflicts. Each server had its own specification of environment variables.

To mitigate this, a common standard for request environment variables was established named Common Gateway Interface.

Some cgi request environemnt vars

WSGI

Python community took a step ahead and along with CGI environment variables, they standardized the way, external scripts must be executed. This standardization was named as WSGI(Web Server Gateway Interface). It is described in python doc PEP 3333.

This specification ensures that every python external script called from a web server must have a particular callable object (class/ method/ function/ instance having __call__ method) as below:

There are 2 sides of WSGI:

Application/Framework: Python web frameworks actually act as external scripts that conform to the WSGI protocol by implementing a callable object as described in above figure. WSGI compatible servers execute this object for each request.
Server/Gateway: WSGI servers implement the functionality to execute the callable object. Web servers like Apache, Nginx are not able to do this task so intermediate servers like gunicorn, uWSGI play the part in between. They take http requests from web servers, call the WSGI object with the request and send back the response to web servers.

Power of WSGI servers is that, a python web application built in any python framework can use any WSGI server like gunicorn, uWSGI. Python developers can write future web servers/ web frameworks using WSGI specification so that web server or web framework would be portable to any other available option.

Some more about WSGI Web Servers

- No Interpreter Restart

Going back to CGI external scripts for a moment. There is a limitation with external scripts that, for each new request, web server has to restart the python interpreter and run the script. This slows down the process a lot.
One of the potential benefits of the WSGI server is that now web server doesn't have to spin-up the new python interpreter for each new request. Instead the web server passes the request to WSGI server that runs the WSGI callable object/function repeatedly for each request. This approach is way more robust.

- Pre-Forking

One bottleneck is the time web servers take to create a new process for each request in order to execute the callable object.
Pre-forking is a technique where web servers pre fork the external script processes in idle time or in python world, WSGI servers create new processes beforehand to run the callable object against each http request. These processes are called workers, you can even create threads to those workers.
HTTP servers like Nginx can't pre-fork so that's also another reason to fit in the WSGI servers in between Nginx and python web applications.

for more, visit the links 1 2 3
hope you learnt something :)

Forem: Afraz Khan

How to setup Corporate Identity Access at scale in AWS?

Federate Access to Your Applications

AWS-Managed Applications

Custom Applications

Trusted Identity Propagation

S3 Access Grants Use Case

Setup Guide

Identity Enhanced IAM Role Sessions

Trusted Identity Propagation(TIP) IN Action

Sample Notebook

Implementing Single Sign-On (SSO) in Your Microsoft Teams Bot App [Part II]

Teams Bot App SSO

SSO Setup

OAuth Dialog Flow

No User Consent

Code Changes for a Node.js Bot Backend

Building a Microsoft Teams Bot App – Step-by-Step Setup Guide [Part I]

Prerequisites

Step 1: Microsoft Entra ID App Registration

Step 2: Setting up the Bot Backend Service

Step 3: Bot Registration in Azure Bot Service

Step 4: App Registration in Teams Developer Portal

Step 5: App Distribution

Sample Bot UI

Whitelisting URL Paths Using Regular Expressions

Why Use Regular Expressions?

Creating the Whitelist

Complete Express.js Example

Transforming TypeScript Enums into Object Arrays

String enum

Numeric enum

Heterogeneous enum

Elevating Code Flexibility: Dependency Inversion with DI Containers

Preliminary Setup

AppContainer.ts

Practical Use Case

👇 Current Code Structure

Authenticator.ts

⭕ Tight Coupling found

🍯 Desired Objective

🔍 Analysis

Resolution

IIdentityProvider.ts

GoogleIdentityProvider.ts

AmazonIdentityProvider.ts

Authenticator.ts

AppContainer.ts

AuthController.ts

Default Implementation with Decorator Pattern

Reuse Redis Connections across AWS Lambda invocations

1. Make use of Lambda Static Initialization

2. Setup Idle Connection Timeout in Redis/database

3. Update Redis Client Creation Logic

Cross-Account Deployment with AWS SAM

Problem

Resolution

CodeBuild Project Location

1. CodeBuild project placed in Dev-Account

2. CodeBuild project placed in DevOps-Account

SAM --role-arn arg

Merge TypeScript Enums

Merge Enums

Sample usage

Merge Issues

Numbered Enums

Duplicate Keys

Nested Enums

AWS Cognito JWT Verification

Refresh Tokens

How to use Refresh-Token?

RefreshToken Revocation

JWT Whitelist

JWT Blacklist

Unique Claims

Some Stateless techniques

Python WSGI Applications

Some History

External Scripts

CGI (Common Gateway Interface)

`AppContainer.ts`

`Authenticator.ts`

`IIdentityProvider.ts`

`GoogleIdentityProvider.ts`

`AmazonIdentityProvider.ts`

`Authenticator.ts`

`AppContainer.ts`

`AuthController.ts`