Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к службам федерации 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 haslifetime=DeviceUsageWindowInDays
orSsoLifetime
, 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 получает запрос на проверку подлинности от клиента.
AD FS проверяет идентификатор клиента в запросе проверки подлинности с идентификатором клиента, полученным во время регистрации клиента и ресурса в AD FS. При использовании конфиденциального клиента AD FS также проверяет секрет клиента, предоставленный в запросе проверки подлинности. AD FS также проверяет URI перенаправления клиента.
AD FS определяет ресурс, к которому клиент хочет получить доступ через параметр ресурса, переданный в запросе проверки подлинности. Если вы используете клиентскую библиотеку MSAL, параметр ресурса не отправляется. Вместо этого URL-адрес ресурса отправляется как часть параметра области: scope = [url-адрес ресурса]/[значения области, например openid].
Если ресурс не передается с помощью параметров ресурса или области, AD FS использует ресурс
urn:microsoft:userinfo
по умолчанию, чьи политики, такие как MFA, выдача или авторизация, не могут быть настроены.Далее AD FS проверяет, имеет ли клиент разрешения на доступ к ресурсу. AD FS также проверяет, соответствуют ли области, переданные в запросе проверки подлинности, заданным при регистрации ресурса. Если у клиента нет разрешений или правильные области не отправляются в запросе проверки подлинности, поток проверки подлинности завершается.
Once permissions and scopes validate, AD FS authenticates the user by using the configured authentication method.
Если требуется другой метод проверки подлинности в соответствии с политикой ресурсов или глобальной политикой проверки подлинности, AD FS активирует дополнительную проверку подлинности.
AD FS использует многофакторную проверку подлинности Microsoft Entra или стороннюю многофакторную проверку подлинности для выполнения проверки подлинности.
Once the user is authenticated, AD FS applies the claim rules. Правила утверждений определяют утверждения, отправленные ресурсу в рамках маркеров безопасности. AD FS также применяет политики контроля доступа , которые подтверждают, что пользователь удовлетворяет необходимым условиям для доступа к ресурсу.
Затем AD FS создает доступ и обновляет маркеры. AD FS также создает токен идентификатора.
AD FS получает запрос проверки подлинности.
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.После создания и настройки необходимых маркеров 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) совпадает с идентификатором клиента.
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 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. |