DEV Community: Lucas Ferreira

Using the API Gateway Authorizer with multi user-pools

Lucas Ferreira — Fri, 24 Sep 2021 17:50:27 +0000

Context

I've been working on a project with a multi-tenancy architecture, and during the refactor from single-tenant to multi-tenant, we had a problem with AWS Cognito and the AWS API Gateway Authorizer.

The problem was, we wanted to add multi Cognito User Pools to our Authorizer and use it to check the token in Cognito, something like this:

With SDK:

import { APIGateway } from 'aws-sdk';

const update_authorizer = async (apigateway: APIGateway, op: 'remove' | 'add') => {
    const params: APIGateway.Types.UpdateAuthorizerRequest = {
        authorizerId: 'x99xxx', /* required */
        restApiId: 'xxxx99xxxx', /* required */
        patchOperations: [ // adding all user pools to the same authorizer
            { // CognitoUserPoolTenantA
                op,
                path: '/providerARNs',
                value: 'arn:aws:cognito-idp:us-east-1:xxxxxxxxxxxx:userpool/us-east-1_xxxxxxxxx',
            },
            { // CognitoUserPoolTenantB
                op,
                path: '/providerARNs',
                value: 'arn:aws:cognito-idp:us-east-1:xxxxxxxxxxxx:userpool/us-east-1_yyyyyyyyy',
            },
            // and keep going adding new User Pools
        ],
    };
    await apigateway.updateAuthorizer(params).promise();
};

// calling the script
const apigateway = new APIGateway({ region: 'us-east-1' });
await update_authorizer(apigateway, 'add');

With Cloud Formation:

Resources:
  ApiGatewayAuthorizer:
    DependsOn:
      - SharedApiGateway
    Type: AWS::ApiGateway::Authorizer
    Properties:
      Name: Authorizer
      IdentitySource: method.request.header.Authorization
      RestApiId:
        Ref: SharedApiGateway
      Type: COGNITO_USER_POOLS
      ProviderARNs:
        - Fn::GetAtt: ['CognitoUserPoolTenantA', Arn]
        - Fn::GetAtt: ['CognitoUserPoolTenantB', Arn]
        # keep going adding new User Pools in the file
        # or adding with the SDK.

Problems during implementation

The API Authorizer has a default cache with the time for invalidation equal to 300 seconds. See more here.
After the changes made by the update_authorizer() function, we saw that the tokens were taking some time to work until we found the createDeployment() inside the AWS SDK for API Gateway.

Final solution

We had to add new functions to the same file where we wrote the first function (update_authorizer).

// ...
const release_api_deployment = async (apigateway: APIGateway) => {
    const params: APIGateway.Types.CreateDeploymentRequest = {
        restApiId: 'xxxx99xxxx', /* required */
        stageName: 'dev',
    };
    await apigateway.createDeployment(params).promise();
};

const flush_authorizers = async (apigateway: APIGateway) => {
    const params: APIGateway.Types.FlushStageAuthorizersCacheRequest = {
        restApiId: 'xxxx99xxxx', /* required */
        stageName: 'dev', /* required */
    };
    await apigateway.flushStageAuthorizersCache(params).promise();
};

// final call
const execute = async () => {
    const apigateway = new APIGateway({ region: 'us-east-1' });
    await update_authorizer(apigateway, 'remove');
    await flush_authorizers(apigateway); // clean cache
    await release_api_deployment(apigateway); // release a new version of the API

    // ... and to test the API we need to generate new tokens
};

try {
    execute();
} catch (error) {
    console.error(error);
}

So with those scripts, we can update the API Gateway Authorizer to works with multi Cognito User Pools without implement a Custom Authorization Lambda.

Serverless básico

Lucas Ferreira — Thu, 23 Sep 2021 16:59:24 +0000

Serverless é uma arquitetura baseada em funções como um serviço (FaaS - Function as a Service), o principal objetivo é que o desenvolvedor se preocupe apenas com o código da função (lógica do negócio) e a responsabilidade pela configuração do ambiente/máquina que vai rodar o código fique por conta do provedor de cloud.

Características

Ambiente sem estado para rodar o código, cada evento que aciona a função PODE ser processado em um ambiente completamente novo, isso limita por exemplo a utilização do sistema de arquivos do ambiente onde o código está rodando e um novo processamento está desacoplado dos processamentos anteriores.
Tempo de execução limitado, o processamento deve ocorrer dentro de um período de tempo, se a execução não estiver completa o ambiente onde o código está rodando simplesmente morre.
Orientado a eventos, cada função de uma aplicação serverless tem um ou mais gatilhos que acionam a execução do código.

Código básico com o framework Serverless

# serverless.yml
provider:
  name: aws
  runtime: nodejs14.x
  memorySize: 512
  timeout: 3

functions:
  users:
    handler: ./UserHandler.handler
    events:
      - http:
          method: GET
          path: users
          cors: true

// UserHandler.js
// aws sample
exports.handler =  async function(_event, _context) {
    const service = new UserService();
    const response = await service.findAll();
    return JSON.stringify(response);
}

Com o comando abaixo é possível realizar a implantação da função no provedor de cloud.

npx serverless deploy

Quando uma requisição chegar na rota registrada no API Gateway um novo evento será disparado e este evento pode ser processado por uma função nova (cold) ou por uma função ativa (warm).

Diferenças entre serverless e uma arquitetura cloud com contêineres

Uma grande diferença é que o serverless te força a quebrar suas operações e definir muito bem qual a responsabilidade da função. Isso é imposto basicamente pelo tempo limite de execução e pelos valores maiores cobrados para execuções com tempo maior ou com consumo de memória maior.
As funções serverless ficam desativadas quando não existem eventos para processar, diferentemente de um contêiner rodando uma aplicação que fica 100% do tempo rodando mesmo sem requisições.

Principais ferramentas

Serverless framework.
AWS Lambda.
Azure Functions.
Google Cloud Functions.
Infraestrutura como código.

Referencias

How to mock the aws-sdk?

Lucas Ferreira — Thu, 09 Sep 2021 17:19:02 +0000

Class to be tested

import { Lambda } from 'aws-sdk';

export default class Service {
    public async callLambda(): Promise<void> {
        const lambda = new Lambda();
        const params: Lambda.Types.InvocationRequest = {
            FunctionName: `function-name`,
            InvocationType: 'Event',
        };
        await lambda.invoke(params).promise();
    }
}

Let suppose that we have a service that call a lambda using the aws-sdk library.
aws-sdk version: 2.546.0.

Unit test with the mock

First way

import Service from '../../../../src/api/services/Service';

const fakePromise = {
    promise: jest.fn(),
};

jest.mock('aws-sdk', () => ({
    Lambda: jest.fn(() => ({
        invoke: () => fakePromise,
    })),
}));

describe('callLambda', () => {

    it('should return something... ', async done => {
        const service = new Service();
        const result = await service.callLambda();
        expect(result).toBeUndefined();
        done();
    });

    it('should throw an error... ', async done => {
        // modifying the implementation before call the function
        fakePromise.promise = jest.fn()
            .mockImplementation(() => Promise.reject(new Error()));

        try {
            const service = new Service();
            const result = await service.callLambda();
            expect(result).toBeUndefined();
        } catch (error) {
            expect(error).toBeDefined();
        }
        done();
    });
});

Second way

import { Lambda } from 'aws-sdk';
import Service from '../../../../src/api/services/Service';

// removing the factory function of the first way
jest.mock('aws-sdk');

describe('callLambda', () => {
    // moving the fake to inside our describe test
    // because we don't need it in jest.mock
    const fakePromise = {
        promise: jest.fn(),
    };

    beforeEach(() => {
        // adding the implementation before each test
        (Lambda as any).mockImplementation(() => {
            return {
                invoke: () => fakePromise,
            };
        });
    });

    it('should return something... ', async done => {
        const service = new Service();
        const result = await service.callLambda();
        expect(result).toBeUndefined();
        done();
    });

    it('should throw an error... ', async done => {
        // modifying the implementation before call the function
        fakePromise.promise = jest.fn()
            .mockImplementation(() => Promise.reject(new Error()));

        try {
            const service = new Service();
            const result = await service.callLambda();
            expect(result).toBeUndefined();
        } catch (error) {
            expect(error).toBeDefined();
        }
        done();
    });
});

Inside the unit tests we can just change the fakePromise or update the mockImplementation to pretend the behaviors that we need.
We can use these approaches to create unit test for other classes inside the aws-sdk.
jest version: 24.9.0.

Conclusion

The most difficult part of writing unit test is creating the mocks for external libraries, the purpose of this article is just help someone with troubles to mock this kind of library. We have a lot of ways to mock libraries, feel free to comment and send suggestions.