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

Поставщики сеансов единого входа в Azure Active Directory B2C

  • Статья

В статье Настройка режима работы сеанса в Azure Active Directory B2C описывается управление сеансами для настраиваемой политики Azure AD B2C. В этой статье описывается, как дальше настроить поведение единого входа для любого отдельного технического профиля в настраиваемой политике.

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

Поставщики сеансов можно применять к двум потокам:

  • Новый вход
    • Если пользователь входит впервые, сеанс не создается. Все технические профили, в которых используется поставщик сеансов, становятся участниками сеанса.
    • Поставщик сеансов может записывать утверждения в файл cookie сеанса.
  • Последующие входы
    • Если пользователь имеет активный сеанс, утверждения в файле cookie сеанса считываются в контейнер утверждений.
    • Утверждения в файле cookie сеанса нельзя обновить.
    • Поставщик сеансов может выдать дополнительные утверждения в контейнер утверждений, обозначая, что этот технический профиль был выполнен в соответствии с условиями единого входа.
    • Технический профиль можно пропустить.

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

  • Предотвращение или применение прерывания пользовательского интерфейса во время последующих входов (единый вход).
  • Запоминание выбранного поставщика удостоверений для последующих входов (единый вход).
  • Сокращение числа операций чтения в каталог при последующих входах (единый вход).
  • Отслеживание сеансов поставщика удостоверений социальных сетей для выполнения выхода поставщика удостоверений.
  • Отслеживание выполнивших вход приложений, основанных на утверждениях, для единого выхода.

Поставщики сеансов

Существует пять поставщиков сеансов для управления тем, как технический профиль работает с сеансом единого входа. При настройке технического профиля необходимо выбрать самый подходящий поставщик сеансов.

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

Поставщик сеансов Применимые типы технических профилей Цель Запись утверждений Чтение утверждений
DefaultSSOSessionProvider Самоподтверждаемый, идентификатор Microsoft Entra, многофакторная проверка подлинности Microsoft Entra, преобразование утверждений Пропускает выполнение технического профиля. Да Да
ExternalLoginSSOSessionProvider Поставщик удостоверений OAuth1, поставщик удостоверений Oauth2, поставщик удостоверений OpenID Connect, поставщик удостоверений SAML Переход на страницу "Выбор поставщика удостоверений". Выполнение единого выхода. Да Да
OAuthSSOSessionProvider Поставщик токенов JWT Управляет сеансом между проверяющей стороной OAuth2 или OpenID Connect и Azure AD B2C. Выполняет однократный выход. Нет Нет
SamlSSOSessionProvider Издатель токенов JWT Управляет сеансом между проверяющей стороной SAML и Azure AD B2C. Выполняет однократный выход. Нет Нет
NoopSSOSessionProvider Любой Не допускает присоединение любого технического профиля к этому сеансу. Нет Нет

На следующей схеме показаны типы сеансов, используемых Azure AD B2C.

Схема, показывающая Azure AD типов B2C поставщиков сеансов.

Ссылка на поставщик сеансов

Чтобы использовать поставщик сеансов в техническом профиле, сделайте следующее:

  1. Создайте технический профиль управления сеансами. Учтите, что начальный пакет 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>

  2. Укажите ссылку на технический профиль управления сеансами в своем техническом профиле. Это позволит управлять поведением этого технического профиля при последующих входах (единый вход).

    Чтобы указать ссылку на технический профиль управления сеансами из своего технического профиля, добавьте элемент 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. Например, поставщик удостоверений SAML для AD-FSContoso-SAML2 использует технический профиль управления сеансами 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>

Метаданные

attribute Обязательно Описание
IncludeSessionIndex Нет В настоящее время не используется, можно игнорировать.
RegisterServiceProviders Нет Указывает, что поставщик должен зарегистрировать все поставщики услуг 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>

Дальнейшие действия

Узнайте, как настроить режим работы сеанса.