Поделиться через


Основные концепции AD FS OpenID Connect/OAuth

Применимо к службам федерации Active Directory (AD FS) 2016 и более поздних версий

Современные субъекты проверки подлинности

Actor Description
End user Субъект безопасности (пользователи, приложения, службы и группы), который обращается к ресурсу.
Client Веб-приложение, определяемое его идентификатором клиента. Клиент обычно является стороной, с которой взаимодействует конечный пользователь, и запрашивает маркеры от сервера авторизации.
Сервер авторизации или поставщик удостоверений (IdP) Ваш сервер AD FS. Он отвечает за проверку удостоверения субъектов безопасности, существующих в каталоге организации. Он выдает маркеры безопасности (маркер доступа носителя, маркер идентификатора и маркер обновления) после успешной проверки подлинности этих субъектов безопасности.
Сервер ресурсов, поставщик ресурсов или проверяющая сторона Где находится ресурс или данные. Он доверяет серверу авторизации для безопасной проверки подлинности и авторизации клиента и использует маркеры доступа носителя, чтобы обеспечить доступ к ресурсу.

На следующей схеме представлена самая базовая связь между субъектами:

Схема современных субъектов проверки подлинности.

Application types

Application Type Description Role
Native application Sometimes called a public client. Он предназначен для клиентского приложения, работающего на компьютере или устройстве, с которым взаимодействует пользователь. Запрашивает токены с сервера авторизации (AD FS) для доступа пользователя к ресурсам. Отправляет HTTP-запросы в защищенные ресурсы с помощью маркеров в качестве заголовков HTTP.
Серверное приложение (веб-приложение) Веб-приложение, которое работает на сервере и доступно пользователям через браузер. Because it's capable of maintaining its own client secret or credential, it's sometimes called a confidential client. Запрашивает токены с сервера авторизации (AD FS) для доступа пользователя к ресурсам. Прежде чем запрашивать токен, клиент (веб-приложение) должен аутентифицироваться, используя свой секрет.
web API Конечный ресурс, к которому обращается пользователь. Подумайте об этом как о новом представлении сторон, которые на что-то полагаются. Использует токены доступа с носителем, полученные клиентами.

Application group

Необходимо связать группу приложений с каждым собственным или веб-клиентом OAuth или ресурсом веб-API, настроенным с помощью AD FS. Настройте клиенты в группе приложений для доступа к ресурсам в той же группе. Группа приложений может иметь несколько клиентов и ресурсов.

Security tokens

Современная проверка подлинности использует следующие типы маркеров:

  • id_token: A JWT token issued by authorization server (AD FS) and consumed by the client. Утверждения в токене идентификатора содержат сведения о пользователе, чтобы клиент смог использовать эти данные.
  • access_token: A JWT token issued by authorization server (AD FS) and intended to be consumed by the resource. Утверждение "aud" или аудитории этого токена должно соответствовать идентификатору ресурса или веб-API.
  • refresh_token: Issued by AD FS for the client to use when it needs to refresh the id_token and access_token. Маркер непрозрачный для клиента и используется только в Active Directory Federation Services.

Продолжительность существования токена обновления

  • Простой вход, без KMSI, устройство не зарегистрировано: применяется AD FS SsoLifetime и DeviceUsageWindowInDays. The first refresh token has lifetime=DeviceUsageWindowInDays or SsoLifetime, based on which field is lower but no further refresh tokens are issued.
  • EnableKmsi=true применяется kmsi=true к . Первый маркер обновления имеет lifetime=DeviceUsageWindowInDays, а каждый последующий запрос grant_type=refresh_token получает новый маркер обновления. Этот процесс происходит только с собственными клиентами или конфиденциальными клиентами и аутентификацией устройств.
  • Зарегистрированные устройства, проверка подлинности устройств: AD FS использует PersistentSsoLifetimeMins и DeviceUsageWindowInDays аналогично KMSI. И собственные, и конфиденциальные клиенты должны получать новые токены обновления, основанные на аутентификации устройства.

Дополнительные сведения см. в документации по единому входу AD FS.

Scopes

При регистрации ресурса в AD FS можно настроить области, позволяющие AD FS выполнять определенные действия. Наряду с настройкой области необходимо отправить значение области в запросе AD FS для выполнения действия. Например, администратор настраивает область как openid во время регистрации ресурсов, а приложение (клиент) должно отправить scope = openid в запросе аутентификации для AD FS, чтобы сервер выдал ID Token. Ниже приведены сведения о доступных областях в AD FS:

  • aza. Если вы используете расширения протокола OAuth 2.0 для клиентов брокера и если параметр области содержит область aza, сервер выдает новый первичный маркер обновления. Он устанавливает токен в поле refresh_token ответа и задает refresh_token_expires_in field время существования нового первичного токена обновления, если такое требование введено.
  • openid. Позволяет приложению запрашивать использование протокола аутентификации для подключения openid.
  • logon_cert. Позволяет запрашивать сертификаты входа в приложение, которые можно использовать для интерактивного входа пользователей с проверкой подлинности. Сервер AD FS пропускает параметр access_token из ответа и вместо этого предоставляет цепочку сертификатов CMS в кодировке Base64 или полный ответ PKI CMC. Дополнительные сведения см. в разделе MS-OAPX: расширения протокола OAuth 2.0.
  • user_impersonation . Запрашивает маркер доступа от имени от AD FS. Дополнительные сведения об использовании этого контекста см. в разделе Создание многоуровневого приложения с использованием On-Behalf-Of (OBO) и OAuth в AD FS 2016.
  • allatclaims – Позволяет приложению запрашивать утверждения в токене доступа, чтобы их также можно было добавить в токен идентификатора.
  • vpn_cert. Позволяет приложению запрашивать VPN-сертификаты, которые устанавливают VPN-подключения с помощью проверки подлинности EAP-TLS. Эта функция больше не поддерживается.
  • email. Позволяет приложению запрашивать адрес электронной почты авторизованного пользователя.
  • profile. Позволяет приложению запрашивать утверждения, связанные с профилем пользователя, вошедшего в систему.

Claims

Токены безопасности (токены доступа и удостоверения), выданные AD FS, содержат утверждения сведений о субъекте, прошедшем проверку подлинности. Приложения могут использовать утверждения для различных задач, в том числе:

  • Проверка токена
  • Определение арендатора каталога субъекта
  • Отображение сведений о пользователе
  • определение авторизации субъекта.

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

Высокоуровневый процесс проверки подлинности AD FS

Ниже представлена схема потока верхнего уровня.

Схема потока проверки подлинности AD FS.

  1. AD FS получает запрос на проверку подлинности от клиента.

  2. AD FS проверяет идентификатор клиента в запросе проверки подлинности с идентификатором клиента, полученным во время регистрации клиента и ресурса в AD FS. При использовании конфиденциального клиента AD FS также проверяет секрет клиента, предоставленный в запросе проверки подлинности. AD FS также проверяет URI перенаправления клиента.

  3. AD FS определяет ресурс, к которому клиент хочет получить доступ через параметр ресурса, переданный в запросе проверки подлинности. Если вы используете клиентскую библиотеку MSAL, параметр ресурса не отправляется. Вместо этого URL-адрес ресурса отправляется как часть параметра области: scope = [url-адрес ресурса]/[значения области, например openid].

    Если ресурс не передается с помощью параметров ресурса или области, AD FS использует ресурс urn:microsoft:userinfo по умолчанию, чьи политики, такие как MFA, выдача или авторизация, не могут быть настроены.

  4. Далее AD FS проверяет, имеет ли клиент разрешения на доступ к ресурсу. AD FS также проверяет, соответствуют ли области, переданные в запросе проверки подлинности, заданным при регистрации ресурса. Если у клиента нет разрешений или правильные области не отправляются в запросе проверки подлинности, поток проверки подлинности завершается.

  5. Once permissions and scopes validate, AD FS authenticates the user by using the configured authentication method.

  6. Если требуется другой метод проверки подлинности в соответствии с политикой ресурсов или глобальной политикой проверки подлинности, AD FS активирует дополнительную проверку подлинности.

  7. AD FS использует многофакторную проверку подлинности Microsoft Entra или стороннюю многофакторную проверку подлинности для выполнения проверки подлинности.

  8. Once the user is authenticated, AD FS applies the claim rules. Правила утверждений определяют утверждения, отправленные ресурсу в рамках маркеров безопасности. AD FS также применяет политики контроля доступа , которые подтверждают, что пользователь удовлетворяет необходимым условиям для доступа к ресурсу.

  9. Затем AD FS создает доступ и обновляет маркеры. AD FS также создает токен идентификатора.

  10. AD FS получает запрос проверки подлинности.

  11. If you include the scope = allatclaims in the authentication request, it customizes the ID token to include claims in the access token based on the defined claim rules.

  12. После создания и настройки необходимых маркеров AD FS отвечает клиенту и включает маркеры. Ответ токена идентификатора включается только в ответ, если аутентификационный запрос содержит scope = openid. Клиент всегда может получить токен идентификатора после авторизации, используя точку доступа токена.

Типы библиотек

Используйте два типа библиотек с AD FS:

  • Client libraries: Native clients and server apps use client libraries to get access tokens for calling a resource such as a web API. Библиотека проверки подлинности Майкрософт (MSAL) — это последняя и рекомендуемая клиентская библиотека при использовании AD FS 2019.

  • Библиотеки ПО промежуточного слоя сервера: веб-приложения используют библиотеки ПО промежуточного слоя сервера для входа пользователя. Веб-API используют библиотеки ПО промежуточного слоя сервера для проверки маркеров, отправленных собственными клиентами или другими серверами. Open Web Interface for .NET (OWIN) — это рекомендуемая библиотека ПО промежуточного слоя.

Настройка токена идентификатора (дополнительные утверждения в токене идентификатора)

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

Option 1: Use this option when you have a public client and the web app doesn't have a resource that it's trying to access. Для этого варианта требуется:

  • response_mode задано как form_post
  • Идентификатор проверяющей стороны (идентификатор веб-API) совпадает с идентификатором клиента.

Схема AD FS для настройки токена: опция один.

Option 2: Use this option when the web app has a resource that it's trying to access and needs to pass extra claims through the ID token. Вы можете использовать как общедоступные, так и конфиденциальные клиенты. Для этого варианта требуется:

  • response_mode задано как form_post

  • KB4019472 устанавливается на серверах AD FS

  • Область allatclaims назначается паре клиент–RP. Вы можете назначить область с помощью Grant-ADFSApplicationPermission. Используйте Set-AdfsApplicationPermission, если он уже был предоставлен один раз. Командлет PowerShell указан в следующем примере:

    Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
    

Схема настройки опции токена два в AD FS.

Чтобы лучше понять, как настроить веб-приложение в AD FS для получения настраиваемого маркера идентификатора, см. раздел "Пользовательские маркеры идентификаторов" в AD FS 2016 или более поздней версии.

Single log-out

Единый выход завершает все клиентские сеансы, использующие идентификатор сеанса. AD FS 2016 и более поздних версий поддерживает единый выход для OpenID Connect/OAuth. Дополнительные сведения см. в статье "Единый выход" для OpenID Connect с AD FS.

Конечные точки AD FS

Конечная точка AD FS Description
/authorize AD FS возвращает код авторизации, который можно использовать для получения токена доступа.
/token AD FS возвращает маркер доступа, который можно использовать для доступа к ресурсу, как и в веб-API.
/userinfo AD FS возвращает утверждение о субъекте.
/devicecode AD FS возвращает код устройства и пользовательский код.
/logout AD FS завершает сеанс пользователя.
/keys Открытые ключи AD FS, используемые для подписывания ответов.
/.well-known/openid-configuration AD FS возвращает метаданные OAuth/OpenID Connect.