Поставщики сеансов единого входа в Azure Active Directory B2C
В статье Настройка режима работы сеанса в Azure Active Directory B2C описывается управление сеансами для настраиваемой политики Azure AD B2C. В этой статье описывается, как дальше настроить поведение единого входа для любого отдельного технического профиля в настраиваемой политике.
Например, вы настроили политику для единого входа на уровне арендатора, но вы хотели бы всегда выполнять шаг с многофакторной проверкой подлинности независимо от наличия активного сеанса единого входа. Это можно обеспечить, настроив поставщик сеансов для технического профиля многофакторной проверки подлинности.
Поставщики сеансов можно применять к двум потокам:
- Новый вход
- Если пользователь входит впервые, сеанс не создается. Все технические профили, в которых используется поставщик сеансов, становятся участниками сеанса.
- Поставщик сеансов может записывать утверждения в файл cookie сеанса.
- Последующие входы
- Если пользователь имеет активный сеанс, утверждения в файле cookie сеанса считываются в контейнер утверждений.
- Утверждения в файле cookie сеанса нельзя обновить.
- Поставщик сеансов может выдать дополнительные утверждения в контейнер утверждений, обозначая, что этот технический профиль был выполнен в соответствии с условиями единого входа.
- Технический профиль можно пропустить.
В зависимости от поставщика управления сеансами, выбранного для конкретного технического профиля, поведение сеанса может быть активным или подавленным. В следующем списке представлены некоторые из множества возможных примеров использования поставщиков сеансов:
- Предотвращение или применение прерывания пользовательского интерфейса во время последующих входов (единый вход).
- Запоминание выбранного поставщика удостоверений для последующих входов (единый вход).
- Сокращение числа операций чтения в каталог при последующих входах (единый вход).
- Отслеживание сеансов поставщика удостоверений социальных сетей для выполнения выхода поставщика удостоверений.
- Отслеживание выполнивших вход приложений, основанных на утверждениях, для единого выхода.
Поставщики сеансов
Существует пять поставщиков сеансов для управления тем, как технический профиль работает с сеансом единого входа. При настройке технического профиля необходимо выбрать самый подходящий поставщик сеансов.
В следующей таблице показано, какой поставщик сеансов следует использовать в зависимости от типа технического профиля, которым вы хотите управлять. Некоторые поставщики сеансов позволяют считывать утверждения в файл cookie сеанса и записывать их в него.
Поставщик сеансов | Применимые типы технических профилей | Характер использования | Запись утверждений | Чтение утверждений |
---|---|---|---|---|
DefaultSSOSessionProvider | Самоутверждаемый, идентификатор Microsoft Entra, многофакторная проверка подлинности Microsoft Entra, преобразование утверждений | Пропускает выполнение технического профиля. | Да | Да |
ExternalLoginSOSOSessionProvider | Поставщик удостоверений OAuth1, поставщик удостоверений Oauth2, поставщик удостоверений OpenID Connect, поставщик удостоверений SAML | Переход на страницу "Выбор поставщика удостоверений". Выполнение единого выхода. | Да | Да |
OAuthSSOSessionProvider | Издатель токена JWT | Управляет сеансом между проверяющей стороной OAuth2 или OpenID Connect и Azure AD B2C. Выполняет однократный выход. | No | No |
SamlSSOSessionProvider | Издатель токена SAML | Управляет сеансом между проверяющей стороной SAML и Azure AD B2C. Выполняет однократный выход. | No | No |
NoopSSOSessionProvider | Любое | Не допускает присоединение любого технического профиля к этому сеансу. | No | No |
На следующей схеме показаны типы сеансов, используемых Azure AD B2C.
Ссылка на поставщик сеансов
Чтобы использовать поставщик сеансов в техническом профиле, сделайте следующее:
Создайте технический профиль управления сеансами. Учтите, что начальный пакет Azure AD B2C содержит самые распространенные технические профили управления сеансами. Вы можете указать ссылку на существующий технический профиль управления сеансами (если это применимо).
В следующем фрагменте кода XML показан технический профиль управления сеансами
SM-AAD
в начальном пакете. Поставщик сеансов имеет типDefaultSSOSessionProvider
.<TechnicalProfile Id="SM-AAD"> <DisplayName>Session Mananagement Provider</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <PersistedClaims> <PersistedClaim ClaimTypeReferenceId="objectId" /> <PersistedClaim ClaimTypeReferenceId="signInName" /> <PersistedClaim ClaimTypeReferenceId="authenticationSource" /> <PersistedClaim ClaimTypeReferenceId="identityProvider" /> <PersistedClaim ClaimTypeReferenceId="newUser" /> <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" /> </PersistedClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true" /> </OutputClaims> </TechnicalProfile>
Укажите ссылку на технический профиль управления сеансами в своем техническом профиле. Это позволит управлять поведением этого технического профиля при последующих входах (единый вход).
Чтобы указать ссылку на технический профиль управления сеансами из своего технического профиля, добавьте элемент
UseTechnicalProfileForSessionManagement
. В следующем примере показано использование технического профиля управления сеансамиSM-AAD
. ИзменитеReferenceId
на идентификатор своего технического профиля управления сеансами.<TechnicalProfile Id="{Technical-profile-ID}"> ... <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" /> </TechnicalProfile>
Внимание
Если технический профиль не ссылается на поставщик управления сеансами, применяется поставщик сеансов DefaultSSOSessionProvider, что может привести к непредвиденному поведению.
Примечание.
Во время потока маркеров обновления поставщики управления сеансами не вызываются. Все попытки выдать новый маркер доступа являются копией выпущенных вами исходных утверждений.
Управление утверждениями сеанса
Технические профили управления сеансами контролируют, какие утверждения могут быть прочитаны, записаны или выведены в ходе выполнения настраиваемой политики.
В техническом профиле управления сеансами используйте элементы PersistedClaims
и OutputClaims
для управления утверждениями.
- Сохраненные утверждения — утверждения, которые могут быть записаны в файл cookie сеанса.
- Чтобы утверждение было написано в файл cookie сеанса, оно должно быть частью текущего контейнера утверждений.
- Все записываемые утверждения автоматически возвращаются при последующих входах (единый вход). Исходящие утверждения указывать не нужно.
- Исходящие утверждения — дополнительные утверждения, которые можно вывести в контейнер утверждений в ходе последующих входов (единый вход). Так как исходящие утверждения не возвращаются из сеанса, необходимо задать значение по умолчанию.
Элементы сохраненных и исходящих утверждений демонстрируются в следующем фрагменте кода XML:
<TechnicalProfile Id="SM-AAD">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="objectId" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
</OutputClaims>
</TechnicalProfile>
Поставщики управления сеансами DefaultSSOSessionProvider
и ExternalLoginSSOSessionProvider
можно настроить для управления утверждениями, например в ходе таких операций:
- Новый вход
- Элемент
PersistedClaims
будет записывать утверждения в файл cookie сеанса. Сохраненные утверждения не могут быть перезаписаны.
- Элемент
- Последующие входы
- Каждое утверждение, записываемое в файл cookie сеанса, будет выводиться в контейнер утверждений, доступный для использования на следующем шаге оркестрации.
- Элемент
OutputClaims
будет выводить статические утверждения в контейнер утверждений. Используйте атрибутDefaultValue
, чтобы задать значение исходящего утверждения.
DefaultSSOSessionProvider
Поставщик сеансов DefaultSSOSessionProvider
можно настроить для управления утверждениями в ходе последующих входов (единый вход) и пропуска технических профилей. DefaultSSOSessionProvider
нужно использовать для сохранения и выдачи утверждений, которые требуются на последующих шагах оркестрации и которые не могут быть получены другим способом при последующих входах (единый вход). Например, утверждения, которые могут быть получены при считывании объекта пользователя из каталога.
Следующий технический профиль SM-AAD
имеет тип поставщика сеансов DefaultSSOSessionProvider
. Технический профиль SM-AAD
можно найти в начальном пакете настраиваемых политик.
<TechnicalProfile Id="SM-AAD">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="objectId" />
<PersistedClaim ClaimTypeReferenceId="signInName" />
<PersistedClaim ClaimTypeReferenceId="authenticationSource" />
<PersistedClaim ClaimTypeReferenceId="identityProvider" />
<PersistedClaim ClaimTypeReferenceId="newUser" />
<PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
</OutputClaims>
</TechnicalProfile>
Например, технический профиль управления сеансами SM-AAD
использует поставщик сеансов DefaultSSOSessionProvider
. При применении для технического профиля SelfAsserted-LocalAccountSignin-Email
из начального пакета настраиваемых политик он будет иметь следующее поведение:
- Новый вход
signInName
будет записываться в файл cookie сеанса, так как технический профиль управления сеансами (SM-AAD) настроен с сохранениемsignInName
, а технический профиль со ссылкой на SM-AAD содержитOutputClaim
дляsignInName
. Это поведение применимо ко всем аналогичным утверждениям.
- Последующие входы
- Технический профиль пропускается, и пользователь не увидит страницу входа.
- Контейнер утверждений будет содержать значение
signInName
из файла cookie сеанса, которое было сохранено при новом входе, а любые другие аналогичные утверждения будут сохраняться в файле cookie сеанса. - Технический профиль управления сеансами возвращает утверждение
objectIdFromSession
, так как утвержденияOutput
поставщика сеанса обрабатываются при последующих входах (единый вход). В этом случае утверждениеobjectIdFromSession
в контейнере утверждений указывает, что утверждения пользователя поступают из файла cookie сеанса вследствие единого входа.
ExternalLoginSSOSessionProvider
Поставщик сеансов ExternalLoginSSOSessionProvider
используется для пропуска экрана "Выбор поставщика удостоверений" и выхода из федеративного поставщика удостоверений. Обычно он ссылается на технический профиль, настроенный для федеративного поставщика удостоверений, например Facebook или Идентификатор Microsoft Entra.
- Новый вход
- Элемент
PersistedClaims
будет записывать утверждения в файл cookie сеанса. Сохраненные утверждения не могут быть перезаписаны.
- Элемент
- Последующие входы
- Каждое утверждение, записываемое в файл cookie сеанса, будет выводиться в контейнер утверждений, доступный для использования на следующем шаге оркестрации.
- Элемент
OutputClaims
будет выводить статические утверждения в контейнер утверждений. Используйте атрибутDefaultValue
, чтобы задать значение утверждения. - Если технический профиль, который ссылается на технический профиль управления сеансами, содержит
OutputClaim
, сохраненный в файле cookie сеанса, этот технический профиль будет пропущен.
Следующий технический профиль SM-SocialLogin
имеет тип поставщика сеансов ExternalLoginSSOSessionProvider
. Технический профиль SM-SocialLogin
можно найти в начальном пакете настраиваемых политик.
<TechnicalProfile Id="SM-SocialLogin">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.ExternalLoginSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="AlternativeSecurityId" />
</PersistedClaims>
</TechnicalProfile>
Утверждение AlternativeSecurityId
создается при входе пользователя с помощью внешнего поставщика удостоверений, представляющего уникальный идентификатор пользователя внешнего поставщика удостоверений. Утверждение AlternativeSecurityId
сохраняется таким образом, чтобы при едином входе профиль пользователя можно было считать из каталога без взаимодействия с федеративным поставщиком удостоверений.
Чтобы настроить внешний поставщик сеансов, добавьте ссылку на SM-SocialLogin
из технических профилей OAuth1, OAuth2 или OpenID Connect. Например, Facebook-OAUTH
использует технический профиль управления сеансами SM-SocialLogin
. Дополнительные сведения см. в разделе о начальном пакете настраиваемых политик.
<TechnicalProfile Id="Facebook-OAUTH">
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
</TechnicalProfile>
OAuthSSOSessionProvider
Поставщик сеансов OAuthSSOSessionProvider
используется для управления сеансами Azure AD B2C между проверяющей стороной OAuth2 или OpenID Connect и Azure AD B2C. Azure AD B2C поддерживает единый выход, также называемый SLO. Если пользователь выполняет выход через конечную точку выхода Azure AD B2C, Azure AD B2C очищает файл cookie сеанса пользователя в браузере. Тем не менее пользователь может оставаться вошедшим в другие приложения, использующие Azure Active Directory B2C для аутентификации.
Этот тип поставщиков сеансов позволяет Azure AD B2C отслеживать все приложения OAuth2 или OpenId Connect, в которые выполнил вход пользователь. Во время выхода из одного приложения Azure AD B2C попытается вызвать конечные точки logout
всех других известных приложений, выполнивших вход. Эта функция встроена в поставщик сеансов. При этом отсутствуют сохраненные или исходящие утверждения, доступные для настройки. Следующий технический профиль SM-jwt-issuer
имеет тип поставщика сеансов OAuthSSOSessionProvider
.
<TechnicalProfile Id="SM-jwt-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</TechnicalProfile>
На технический профиль SM-jwt-issuer
указана ссылка в техническом профиле JwtIssuer
:
<TechnicalProfile Id="JwtIssuer">
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
</TechnicalProfile>
SamlSSOSessionProvider
Поставщик сеансов SamlSSOSessionProvider
используется для управления поведением сеанса с помощью федеративных поставщиков удостоверений SAML или приложений проверяющей стороны SAML и Azure AD B2C.
Управление сеансами поставщика удостоверений SAML
При указании ссылки на поставщик сеансов SamlSSOSessionProvider
из сеанса поставщика удостоверений SAML для RegisterServiceProviders
нужно задать значение false
.
Следующий технический профиль SM-Saml-idp
имеет тип поставщика сеансов SamlSSOSessionProvider
.
<TechnicalProfile Id="SM-Saml-idp">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="RegisterServiceProviders">false</Item>
</Metadata>
</TechnicalProfile>
Чтобы использовать технический профиль управления сеансами SM-Saml-idp
, добавьте ссылку на технический профиль поставщика удостоверений SAML. Например, поставщик Contoso-SAML2
удостоверений SAML AD-FS использует SM-Saml-idp
технический профиль управления сеансами.
<TechnicalProfile Id="Contoso-SAML2">
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp" />
</TechnicalProfile>
Управление сеансами поставщика службы SAML
При указании ссылки на поставщик сеансов SamlSSOSessionProvider
для управления сеансом проверяющей стороны SAML для RegisterServiceProviders
нужно задать значение true
. Для завершения входа в сеанс SAML требуются SessionIndex
и NameID
.
Следующий технический профиль SM-Saml-issuer
имеет тип поставщика сеансов SamlSSOSessionProvider
.
<TechnicalProfile Id="SM-Saml-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</TechnicalProfile>
Чтобы использовать технический профиль управления сеансами SM-Saml-issuer
, добавьте ссылку на технический профиль издателя токена SAML. Например, технический профиль Saml2AssertionIssuer
использует технический профиль управления сеансами SM-Saml-issuer
.
<TechnicalProfile Id="Saml2AssertionIssuer">
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
</TechnicalProfile>
Метаданные
Атрибут | Обязательное поле | Описание |
---|---|---|
IncludeSessionIndex | No | В настоящее время не используется, можно игнорировать. |
RegisterServiceProviders | No | Указывает, что поставщик должен зарегистрировать все поставщики услуг SAML, которыми было выдано утверждение. Возможные значения: true (по умолчанию) или false . |
NoopSSOSessionProvider
Поставщик сеансов NoopSSOSessionProvider
используется для подавления поведения единого входа. Технические профили, использующие этот тип поставщика сеансов, всегда будут обрабатываться даже в том случае, если у пользователя есть активный сеанс. Этот тип поставщика сеансов может быть полезен для принудительного запуска определенных технических профилей, например для следующего:
- Преобразование утверждений — чтобы создать или преобразовать утверждения, которые позже будут использоваться для определения того, какие шаги оркестрация нужно обрабатывать или пропускать.
- Restful — извлекает обновленные данные из служб Restful каждый раз при выполнении политики. Вы также можете вызвать Restful для расширенного входа и аудита.
- С самостоятельным подтверждением — вынуждает пользователя предоставлять данные каждый раз при запуске политики, например для проверки адресов электронной почты с помощью одноразового секретного кода или запроса согласия пользователя.
- Phonefactor . Принудительное выполнение многофакторной проверки подлинности в рамках "поэтапной проверки подлинности" даже во время последующего входа (единый вход).
Такой тип поставщиков сеансов не сохраняет утверждения в файле cookie сеанса пользователя. Следующий технический профиль SM-Noop
имеет тип поставщика сеансов NoopSSOSessionProvider
. Технический профиль SM-Noop
можно найти в начальном пакете настраиваемых политик.
<TechnicalProfile Id="SM-Noop">
<DisplayName>Noop Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.NoopSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</TechnicalProfile>
Чтобы подавить поведение единого входа для технического профиля, добавьте ссылку на технический профиль SM-Noop
. Например, AAD-Common
использует технический профиль управления сеансами SM-Noop
. Дополнительные сведения см. в разделе о начальном пакете настраиваемых политик.
<TechnicalProfile Id="AAD-Common">
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Следующие шаги
Узнайте, как настроить режим работы сеанса.