Технология единого входа: OAuth

Технология единого входа (SSO) - это механизм аутентификации, который позволяет пользователям получать доступ к нескольким приложениям или сервисам с помощью одной учетной записи. Вместо того чтобы использовать отдельные учетные данные для входа в каждое приложение, SSO позволяет пользователям войти в систему один раз, а затем их аутентифицированная сессия разделяется между различными приложениями, не требуя повторного входа в систему.

OAuth (Open Authorization) - это открытый стандарт и широко используемый протокол для безопасного предоставления доступа к ресурсам от имени пользователя без разглашения его учетных данных.

Для отдельных экземпляров AggreGate схема авторизации по умолчанию представляет собой режим автономной работы, в котором экземпляр выступает в роли провайдера идентификационных данных, выдавая и проверяя пользовательские токены внутри себя.

С помощью плагина OAuth один или несколько экземпляров AggreGate можно настроить на использование общего внешнего поставщика идентификационных данных. В результате пользователи могут проходить аутентификацию у внешнего провайдера один раз, а затем переходить между несколькими приложениями, разными экземплярами AggreGate, без необходимости повторной аутентификации.

В следующих шагах описано, как реализовать внешнюю авторизацию для повышения безопасности вашего сервера. Основными шагами являются настройка внешнего поставщика идентификационных данных, установка плагина AggreGate OAuth для использования внешнего поставщика, включение плагина на сервере AggreGate и включение авторизации для определенных пользователей.

У каждого внешнего провайдера есть свои методы для настройки внешнего сервиса авторизации. Ниже приведены общие сведения. Когда вы настраиваете производственную систему, обратитесь к документации поставщика услуг.

Настроив управление идентификацией и доступом в Google Cloud, вы сможете предоставлять пользователям доступ к AggreGate путем аутентификации с помощью их аккаунтов Google. Обычно настройка выглядит следующим образом:

• В разделе IAM & Admin панели управления Google Cloud Platform создайте новый проект.

• В разделе APIs & Services откройте страницу конфигурации для OAuth Consent Screen, чтобы создать приложение для управления авторизацией.

  • Создайте экран согласия, тщательно продумав, для каких пользователей будет осуществляться авторизация - внешних или внутренних по отношению к вашей организации на Google Cloud Platform.

• Настройте Scopes (области видимости) для приложения. Области видимости определяют количество информации о пользователе, которую Google возвратит при успешном запросе авторизации. Более широкие области видимости предоставляют больше информации, но требуют дополнительной регистрации в Google перед развертыванием приложения.

• При желании, добавьте тестовых пользователей. Только тестовым пользователям будет разрешено проходить аутентификацию через Google, пока приложение находится в режиме тестирования.

• Опубликуйте приложение.

• В пункте меню Учетные данные на панели администратора приложения откройте опцию Создать учетные данные и выберите Идентификатор клиента OAuth. Информация об идентификаторе клиента будет использована для настройки плагина OAuth AggreGate.

• Определите Тип приложения как Веб-приложение. Введите URI, на которых размещены экземпляры AggreGate, доступ к которым будет разрешен пользователям с помощью OAuth-авторизации. Создайте учетные данные.

• Выберите Загрузить JSON, чтобы сохранить информацию, необходимую для настройки плагина AggreGate OAuth.

Загруженный документ должен быть похож на следующий:

{
  "type": "service_account",
  "project_id": "PROJECT_ID",
  "private_key_id": "KEY_ID",
  "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
  "client_email": "SERVICE_ACCOUNT_EMAIL",
  "client_id": "CLIENT_ID",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}

Добавление приложения на платформе Microsoft Identity Platform выполняется по аналогичным шагам для регистрации веб-службы и клиентских приложений в Azure Active Directory. Обратите внимание, что в этом случае любой пользователь, который будет проходить аутентификацию, должен существовать как в Azure Active Directory, так и в AggreGate.

• На портале Azure Portal откройте Azure Active Directory и выберите Зарегистрировать приложение.

• Укажите имя приложения, выберите, какие типы учетных записей пользователей будут разрешены для аутентификации приложением (внешние или внутренние для вашей организации в Azure AD). Необходимо сгенерировать Уникальный идентификатор приложения, который будет использоваться при добавлении клиентского приложения.

• Определите Тип приложения как Веб-приложение. Определите URI, на которых размещены экземпляры AggreGate, к которым пользователям будет разрешен доступ через авторизацию OAuth.

• Выберите Тип выбора токена как ID токена (Используется для неявных и гибридных потоков).

• В меню Сертификаты и секреты выберите Новый секрет клиента.

• Это создаст письмо с полем подтверждения в токенах авторизации и даст возможность добавить дополнительные параметры токена по желанию.

• От лица администратора, дайте согласие на использование нужных параметров.

• В разделе Предоставление API, выберите Добавить область, чтобы добавить любое количество областей для ограничения доступа к данным и функциям.

• Кликните Добавить клиентское приложение и укажите уникальный идентификатор приложения (клиента), сгенерированный при регистрации приложения.

• Вернитесь к регистрации приложения и откройте вкладку Конечные точки, чтобы получить конечные точки для:

  • Авторизации (Authorization), которая должна выглядеть примерно так: https: //login.microsoftonline.com/<app или tenant id>/oauth/v2.0/authorize

  • Токена доступа (Access Token), который должен выглядеть так: https: //login.microsoftonline.com/<app or tenant id>/oauth/v2.0/token

  • Выхода из системы (Logout), который должен выглядеть примерно так: https: //login.microsoftonline.com/<app или id арендатора>/oauth/v2.0/logout

Существует множество вариантов внешней аутентификации через OAuth, включая ряд облачных сервисов, различные сайты социальных сетей, специальные поставщики услуг идентификации Okta, Auth0, Keycloak и многие другие. Шаги регистрации у каждого из них свои, но примерно они соответствуют приведенной выше логике.

Плагин OAuth на AggreGate, сервере и каждом пользователе должен быть настроен, чтобы использовать преимущества метода внешней аутентификации, описанного выше.

Плагин OAuth управляет взаимодействием между AggreGate и поставщиками идентификационных данных, перенаправляя неаутентифицированных пользователей к поставщикам идентификационных данных OAuth, обрабатывая ответы и предоставляя доступ пользователям, которые уже аутентифицированы.

Следует выполнить следующие шаги:

• Убедитесь, что OAuth-плагин установлен в каждом экземпляре AggreGate, для которого будет разрешен внешний доступ.

• Редактировать глобальные свойства плагина OAuth . Плагин находится в контексте Драйвера и расширения.

• Создайте новую запись и дайте ей уникальное имя в поле Имя плагина, а также удобное описание в поле Описание.

• Откройте поле Настройки, чтобы указать параметры поставщика идентификационных данных.

Для того чтобы AggreGate мог использовать OAuth в качестве метода внешней аутентификации, сервер должен быть

• Откройте Конфигурации сервера, перейдите на вкладку Безопасность, в подвкладке Аутентификация установите для параметра Внешняя аутентификация значение OAuth.

• Перезапустите сервер.

Наконец, каждый пользователь в AggreGate может быть настроен на Использование внешней аутентификации. Включение внешней аутентификации для пользователя означает, что AggreGate позволит ему проходить аутентификацию с помощью службы, указанной в методе Внешняя аутентификация сервера.