Авторизатор шлюза API — политика IAM не кэшируется

Я пытаюсь кэшировать политику IAM, возвращаемую лямбдой авторизатора, когда она впервые проверяет токен JWT. Я включил и установил от authorizerResultTtlInSeconds до 3500 секунд в авторизаторе шлюза API. Тем не менее, я все еще вижу запрос, направляемый в лямбда-функцию Authorizer в течение времени кэширования.

Мой скрипт node.js выглядит следующим образом:

const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

const keyClient = jwksClient({
    jwksUri: process.env.JWKS_URI
})

const allow = {
    "principalId": "user",
    "policyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "execute-api:Invoke",
                "Effect": "Allow",
                "Resource": process.env.RESOURCE // RESOURCE = *
            }
        ]
    }
}

const unauthorized = {
    "error": "Unauthorized",
}

//excluded verificationJWTOptions object and getSigningKey function for simplicity
function validateJWTToken(token, callback) {
    jwt.verify(token, getSigningKey, verificationJWTOptions, (error) => {
        if (error) {
            callback(unauthorized)
        } else {
            callback(null, allow)
        }
    })
}

exports.handler = (event, context, callback) => {
    const token = extractTokenFromHeader(event);
    validateJWTToken(token, callback);
}

Не уверен, что я упускаю. Любая помощь приветствуется!


node.js caching aws-api-gateway lambda-authorizer
person neha    schedule 27.02.2020    source источник
comment
Просмотр журналов выполнения шлюза API для двух запросов может помочь выявить любые проблемы с политикой авторизации или ключом кэша.   -  person TheClassic    schedule 27.02.2020
comment
Я проверил правильно, но не могу найти журналы выполнения шлюза API в группах журналов CloudWatch для сегодняшней даты и времени. То, что я вижу в журналах CloudWatch для лямбда-функции Authorizer, — это только START RequestId, END RequestId и REPORT RequestId (и никакой другой информации).   -  person neha    schedule 27.02.2020
comment
@nrai Попробуйте распечатать данные о событии в функции авторизации и сравните журналы для первого и последующих вызовов. docs.aws.amazon.com/lambda/latest/dg/ nodejs-handler.html   -  person Suraj Bhatia    schedule 28.02.2020

Ответы (1)


arrow_upward
5
arrow_downward

Я понял, что неправильно тестировал логику кэширования авторизатора шлюза API. Я тестировал различные сценарии и нашел здесь два случая:

  • Когда токен действителен: когда вызывается endpoint, запрос направляется авторизатору Lambda, который проверяет/аннулирует токен. IAM-политика возвращается функцией авторизатору шлюза API и кэшируется (в данном случае — для 58 minutes, 20 seconds).

    Имя заголовка, указанное в Token Source, становится ключом кэша, а политика авторизации, созданная авторизатором, становится значением кэша. Шлюз API проверит заголовок, указанный в Token Source. Если значение заголовка соответствует ключу, шлюз API не будет вызывать Lambda Authorizer, а вместо этого проверит, действительна ли политика в соответствии с настроенным TTL.

    Если новый токен генерируется в течение времени кэширования, то снова выполняется вызов Lambda Authorizer, и этот токен кэшируется. Таким образом, если конечная точка вызывается с использованием этих двух токенов, то обращение к Lambda Authorizer не выполняется, поскольку политики IAM для этих токенов уже кэшируются для заданного интервала времени кэширования, и ответ возвращается.

  • Если токен недействителен: например, если токен действителен для 30 minutes с 11:00:00AM по 11:30:00AM, а для кэша TTL задано значение 58 minutes. Клиент делает 2 запроса API, используя этот токен, один в 11:29:59AM, а другой в 11:31:3APM — тогда оба запроса будут приняты, хотя второй использовал токен с истекшим сроком действия. В основном это означает, что JWT token расширяется кешем TTL.

person neha    schedule 02.03.2020