Использование Cognito с C # серверным приложением - PullRequest
Новая
       47

Использование Cognito с C # серверным приложением

0 голосов
/ 05 июля 2018

Я хочу создать приложение без сервера AWS, которое использует AWS Cognito для аутентификации. Моя отправная точка - шаблон AWS Serverless Application with Tests (.NET Core) для C # в Visual Studio 2017. При развертывании шаблон создает некоторые функции Lambda и настраивает AWS API Gateway, чтобы я мог подключаться к функциям Lambda с помощью запросов REST. Это работает.

Я создал пул пользователей в AWS Cognito и клиент javascript (одностраничное приложение), который позволяет пользователю входить в систему с помощью AWS Cognito. В клиенте javascript я могу подключиться к AWS Cognito и получить идентификатор, получить доступ и обновить токены как JWT. Я также могу отправить эти токены в заголовке Authorization: Bearer eyblablabla... на сервер (приложение без сервера AWS). Таким образом, аутентификация клиента javascript и настройка AWS Cognito, похоже, работают. Я также в AWS API Gateway настроил авторизатор, который указывает на пул пользователей AWS Cognito.

Моя проблема заключается в следующем: бэкэнд не знает о заголовке авторизации. При рассмотрении запроса я не получаю никаких претензий к пользователю. Я особенно заинтересован в получении заявления sub, чтобы я мог идентифицировать пользователя. Кроме того, я хотел бы, чтобы шлюз API автоматически отправлял ответ Unauthorized для определенных методов, но я не знаю, как его настроить.

Как часть сигнатуры функции Lambda, я получаю APIGatewayProxyRequest объект запроса. Очевидно, request.RequestContext.Authorizer.Claims должен содержать заявки пользователей, но .Authorizer является нулевым.

Я могу получить любой JWT, который я отправлю от клиента javascript, прочитав заголовок запроса, чтобы я мог проанализировать токен, чтобы получить утверждения пользователей. Но я полагаю, что с моей настройкой должно быть что-то не так, поскольку .Authorizer не заполняется.

Только предложения, которые я нашел до сих пор, включают в себя элементы в файле шаблона serverless.yml или Swagger, ни один из которых не является частью шаблона AWS Serverless Application VS2017. Вместо этого у меня есть serverless.template файл JSON, и нет очевидного способа добавить настройки аутентификации / безопасности в этот файл.

Мой код до сих пор идентичен шаблону приложения без сервера AWS в VS2017.

Любая помощь будет принята с благодарностью.

1 Ответ

0 голосов
/ 13 декабря 2018

Необходимо включить использование интеграции Lambda Proxy в запросе интеграции метода API. Ваш объект APIGatewayProxyRequest будет выглядеть примерно так: 

{
"Resource": "/test",
"Path": "/test",
"HttpMethod": "GET",
"Headers": {
    "Accept": "*/*",
    "accept-encoding": "gzip, deflate",
    "Authorization": "your token",
    "cache-control": "no-cache",
    "CloudFront-Forwarded-Proto": "https",
    "CloudFront-Is-Desktop-Viewer": "true",
    "CloudFront-Is-Mobile-Viewer": "false",
    "CloudFront-Is-SmartTV-Viewer": "false",
    "CloudFront-Is-Tablet-Viewer": "false",
    "CloudFront-Viewer-Country": "US",
    "Host": "xxxxxxx.execute-api.us-east-1.amazonaws.com",
    "Postman-Token": "08820d50-c5d4-498a-bfee-c76994bb91f1",
    "User-Agent": "PostmanRuntime/7.4.0",
    "Via": "1.1 dd169cfdbbafbb3da513bede6bc6640e.cloudfront.net (CloudFront)",
    "X-Amz-Cf-Id": "89ftx9aaVK0k2KOFu-5QESLXzGUGAw17gNCCY03in-hF2hd-LvRhIg==",
    "X-Amzn-Trace-Id": "Root=1-5c125bb9-1e8b9fea8d1beb20147a24d2",
    "X-Forwarded-For": "50.196.109.21, 70.132.33.133",
    "X-Forwarded-Port": "443",
    "X-Forwarded-Proto": "https"
},
"QueryStringParameters": null,
"PathParameters": null,
"StageVariables": null,
"RequestContext": {
    "Path": "/test_oauth/token",
    "AccountId": "xxxxxxxxxxxxx",
    "ResourceId": "luy67k",
    "Stage": "test_oauth",
    "RequestId": "5455133d-fed9-11e8-8f41-ef35907ced2d",
    "Identity": {
        "CognitoIdentityPoolId": null,
        "AccountId": null,
        "CognitoIdentityId": null,
        "Caller": null,
        "ApiKey": null,
        "SourceIp": "50.196.109.21",
        "CognitoAuthenticationType": null,
        "CognitoAuthenticationProvider": null,
        "UserArn": null,
        "UserAgent": "PostmanRuntime/7.4.0",
        "User": null
    },
    "ResourcePath": "/token",
    "HttpMethod": "GET",
    "ApiId": "8xxg9ez961",
    "Authorizer": {
        "claims": {
            "sub": "4560ac4b-54a0-4184-8831-e3cb2583726b",
            "aud": "xxxxxxxxxxxxxxxx",
            "email_verified": "false",
            "event_id": "467633ad-fed9-11e8-88ff-25be6cd15697",
            "token_use": "id",
            "custom:ApplicationId": "12345",
            "auth_time": "1544706978",
            "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-xxxxxxxxx",
            "cognito:username": "username",
            "exp": "Thu Dec 13 14:16:18 UTC 2018",
            "iat": "Thu Dec 13 13:16:18 UTC 2018",
            "email": "user@email.com"
        }
    }
},
"Body": null,
"IsBase64Encoded": false
}

Обратите внимание, что вы получите разные значения, если ваш API-шлюз настроен на использование токена идентификатора по сравнению с токеном доступа (что отличается от использования пользовательских областей OAuth или их отсутствия в настройках API-шлюза). Вы также обнаружите, что результаты зависят от настроек вашего клиентского приложения User Pool - какие области Allowed Oauth включены, а также какие атрибуты включены для ваших клиентов App.

...