Все знают, как обезопасить доступ пользователей к ресурсам. Это просто, поскольку у нас есть человек, который может ввести свой логин и пароль в форму входа на своем экране по запросу. На основе полученных учетных данных провайдер аутентификации сгенерирует токен, и пользователь будет использовать этот токен для доступа к API или любому типу приложения. Но что делать, если пользователя нет, а клиентом нашего API является другая служба? Как эта служба может войти в систему и ввести свои учетные данные? Как получить токен доступа?
Этот тип связи называется службой службе. Сегодня вы узнаете, как защитить его с помощью сервисов AWS, в основном через Amazon Cognito. Мы начнем с концепции безопасной связи, а затем перейдем к части реализации, где мы предоставим вам образцы кода.
Концепция
Структура приложения
Начнем с типичной структуры приложения. В настоящее время почти любое приложение имеет API и некоторые веб-клиенты или мобильные клиенты. Пользователь использует форму входа в систему, чтобы получить токен JWT, а затем включает его во все запросы к API. API проверяет этот токен, извлекает из него информацию, такую как имя пользователя или роли, а затем в некоторых случаях предоставляет ответ или неавторизованное сообщение.
На втором этапе мы хотим представить еще несколько потребителей API. Это фоновые службы, которые работают без участия пользователя, например, служба, которая создает и доставляет электронные письма. В текущей настройке у нас есть защищенный общедоступный API, который используется веб-клиентом. При этом связь с другими сервисами также должна быть защищена.
API приложения как ресурс
Мы можем рассматривать API приложения как поставщика ресурсов или сервер ресурсов. Он предоставляет своим клиентам несколько ресурсов или конечных точек. Например, представим, что первый клиент службы должен экспортировать файлы. Он должен запросить у API ресурс app-api \ export. Второй клиент службы загружает новые файлы в наш магазин, поэтому он потребляет ресурсы app-api \ upload.
Сервер ресурсов - это обычная практика для определения возможностей вашего API или другого приложения. Исходя из этого, каждый клиент службы может определить, какие ресурсы ему нужны, и запросить для них разрешение.
Сервис для управления доступом к сервису в AWS
К счастью, в AWS есть сервис Amazon Cognito, который позволяет нам применять нашу концепцию сервера ресурсов и организовывать контроль доступа к сервисам. Мы просто кратко опишем основные части Amazon Cognito. У AWS есть отличная официальная документация по Cognito; пожалуйста, проверьте это для более подробной информации.
Пул пользователей, хотя это пул пользователей для конкретного приложения, в нашем случае он работает как контейнер для тесно связанной группы Серверов ресурсов , сервисы, предоставляющие некоторые функции, и Клиенты приложений, потребители серверов ресурсов.
Каждому клиенту приложения назначается пара ключа доступа / секретного ключа, которую этот клиент может использовать для аутентификации в Cognito Domain и получения веб-токена JSON. Этот токен используется для аутентификации на одном из серверов ресурсов.
Степень детализации доступа контролируется областями. Каждый сервер ресурсов может предоставлять несколько областей действия, например файл экспорта, файл загрузки и т. Д. Следовательно, каждому клиенту приложения может быть назначено несколько областей действия с нескольких серверов ресурсов.
Затем сервер ресурсов отвечает за проверку действительности JWT и того, содержит ли этот токен области, позволяющие выполнить операцию, запрошенную клиентом приложения.
Безопасный поток обслуживания для обслуживания
Описанные части Cognito позволяют нам создать безопасный коммуникационный поток на основе токена доступа JWT. Процесс прост и состоит всего из нескольких шагов.
1. Сервисный клиент просит Amazon Cognito сгенерировать токен доступа.
2. Amazon Cognito создает токен доступа с разрешенными областями.
3. Клиент службы вызывает API с предоставленным токеном доступа.
4. API запрашивает у Amazon Cognito проверку токена.
5. API возвращает ответ на основе предоставленных областей.
Вот краткое изложение шагов, которые необходимо выполнить, чтобы обеспечить безопасную связь:
1. Создайте пул пользователей Amazon Cognito с собственным доменом.
2. Добавьте новый сервер ресурсов и определите его области действия.
3. Создайте клиентов приложений для своих приложений. У каждого клиента службы есть свой идентификатор клиента и секрет клиента.
4. Определите настройки для каждого клиента приложения, какие области он может использовать и тип аутентификации. В нашем случае это поток Предоставление кода авторизации.
5. В каждом сервисном клиенте реализуйте логику для запроса токена доступа.
6. Настройте API для работы с токенами доступа.
Выполнение
Конфигурация Amazon Cognito
Все необходимые части Amazon Cognito можно легко создать с помощью простого скрипта CloudFormation. Вы можете ознакомиться с ним ниже. Более того, здесь вы получите большую выгоду. Конфигурация безопасности будет храниться в репозитории исходного кода, и любые изменения в ней можно будет легко контролировать. Это означает, что вы будете знать, кто и когда изменил доступ к ресурсам приложения.
Как создать токен доступа
В качестве примеров я буду использовать язык C #, но этот код можно легко переписать на любой другой язык.
В следующем фрагменте кода показано, как запросить токен доступа у Cognito. Вы должны использовать свои собственные ClientId, ClientSecret, Scope , CognitoAuthUrl. Где CognitoAuthUrl - это URL-адрес домена Cognito плюс суффикс / oauth2 / token.
Amazon Cognito возвращает следующую структуру TokenInfo.
Как защитить API
Здесь мы опишем два подхода к реализации. Один из подходов - это специальный код, необходимый для защиты API на основе ASP .NET Core. Другой вариант - использовать собственный AWS Cognito Authorizer для API Gateway.
Пример ASP .NET Core
Для ASP NET Core API есть несколько шагов.
- Добавьте политику авторизации в класс Автозагрузка.
2. Создайте Средство проверки токенов Cognito. Где CognitoPoolUrl - это URL-адрес домена Cognito.
3. Используйте политику Авторизовать, чтобы защитить свои конечные точки.
Авторизация шлюза API
Второй вариант - защитить ваш API с помощью Cognito Authorizer. Эту опцию легко реализовать, если у вас есть API Gateway поверх вашего API.
Затем в Консоли AWS выберите API Gateway, перейдите в Авторизаторы и создайте новый. Выберите тип Cognito, введите Имя авторизатора и выберите свой Пул пользователей. Кроме того, укажите Источник токена - имя заголовка для чтения токена доступа.
Теперь вы можете использовать созданный авторизатор для защиты ваших конечных точек. Выберите метод и перейдите в настройки запроса метода. Здесь настройте авторизацию и выберите авторизатор. Затем для областей OAuth введите одну или несколько областей, которые необходимы для доступа к этой конечной точке.
Вот и все, нужно всего два шага, чтобы защитить ваш API с помощью встроенного Cognito Authorizer.
Резюме
Теперь вы знаете, что аутентификацию можно выполнить без участия пользователя. Благодаря Amazon Cognito у нас есть отличный инструмент для создания защищенной связи между сервисами в AWS. Настроить и работать с ним просто. Более того, всеми настройками безопасности можно управлять через исходный код. Это открывает прекрасную возможность для организации процесса проверки и аудита любых изменений разрешений.
