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

Настройка параметров поставщика удостоверений SAML с помощью Azure Active Directory B2C

  • Статья

Azure Active Directory B2C (Azure AD B2C) поддерживает федерацию с поставщиками удостоверений SAML 2.0. В этой статье описывается, как проанализировать утверждения безопасности и параметры конфигурации, доступные при включении входа с помощью поставщика удостоверений SAML.

Прежде чем начать работу, используйте селектор Choose a policy type (Выбрать тип политики), чтобы выбрать тип пользовательской политики. Azure Active Directory B2C предлагает два метода определения способа взаимодействия пользователей с вашими приложениями: с помощью предопределенных потоков пользователей или полностью настраиваемых пользовательских политик. Действия, которые необходимо выполнить, отличаются для каждого метода.

Эта возможность доступна только для пользовательских политик. Чтобы ознакомиться с этапами установки, в предыдущем селекторе выберите Настраиваемая политика.

Сопоставление утверждений

Элемент OutputClaims содержит список утверждений, возвращаемых поставщиком удостоверений SAML. Возможно, потребуется сопоставить имя утверждения, определенное в вашей политике, с именем, определенным у поставщика удостоверений. В поставщике удостоверений проверьте список утверждений (проверочных утверждений). Вы также можете проверить содержимое ответа SAML, возвращаемого поставщиком удостоверений. Дополнительные сведения см. в разделе Отладка сообщений SAML. Чтобы добавить утверждение, сначала определите утверждение, а затем добавьте утверждение в коллекцию исходящих утверждений.

Можно также включить утверждения, которые не возвращаются поставщиком удостоверений, если задан DefaultValue атрибут . Значение по умолчанию может быть статическим или динамическим благодаря использованию утверждений контекста.

Элемент OutputClaim содержит следующие атрибуты.

  • ClaimTypeReferenceId — это ссылка на тип утверждения.
  • PartnerClaimType — имя свойства, отображаемое как допущение SAML.
  • DefaultValue — это стандартное значение по умолчанию. Если утверждение пустое, используется значение по умолчанию. Можно также использовать арбитры утверждений с контекстным значением, например идентификатор корреляции или IP-адрес пользователя.

Имя субъекта

Чтобы считать утверждение SAML NameId в поле Subject как нормализованное утверждение, задайте для утверждения PartnerClaimType значение атрибута SPNameQualifier. SPNameQualifierЕсли атрибут не представлен, задайте для утверждения PartnerClaimType значение атрибутаNameQualifier.

Утверждение SAML

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

Исходящее утверждение:

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

Если оба SPNameQualifier атрибута или NameQualifier не представлены в утверждении SAML, задайте для утверждения PartnerClaimType значение assertionSubjectName. Убедитесь, что NameId является первым значением в XML утверждения. При определении нескольких утверждений Azure AD B2C выбирает значения субъекта из последнего утверждения.

Настройка привязок протокола SAML

Запросы SAML отправляются поставщику удостоверений, как указано в элементе метаданных поставщика удостоверений SingleSignOnService. Большинство запросов на авторизацию поставщиков удостоверений переносятся непосредственно в строку запроса URL-адреса запроса HTTP GET (так как сообщения относительно короткие). Сведения о настройке привязок для обоих запросов SAML см. в документации поставщика удостоверений.

Следующий XML-код является примером службы единого входа метаданных Microsoft Entra с двумя привязками. HTTP-Redirect имеет приоритет над HTTP-POST, так как отображается первым в метаданных поставщика удостоверений SAML.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

Служба обработчика утверждений

Служба обработчика утверждений (или ACS) — это место, где Azure AD B2C отправляет и получает ответы SAML поставщика удостоверений. Ответы SAML передаются в Azure AD B2C через привязку HTTP POST. Расположение ACS указывает на базовую политику проверяющей стороны. Например, если политика — B2C_1A_signup_signin, то ACS является базовой политикой B2C_1A_signup_signin, например B2C_1A_TrustFrameworkBase.

Следующий XML-код является примером элемента службы-получателя утверждения метаданных политики B2C Azure AD.

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

Настройка подписи запроса SAML

Azure AD B2C подписывает все исходящие запросы проверки подлинности с помощью криптографического ключа SamlMessageSigning. Чтобы отключить подпись запроса SAML, установите для параметра WantsSignedRequests значение false. Если метаданным присвоено значение false, параметры SigAlg и Signature (строка запроса или параметр публикации) не включаются в запрос.

Эти метаданные также определяют атрибут AuthnRequestsSigned, который представляет собой выходные данные в метаданных технического профиля Azure AD B2C, совместно используемого с поставщиком удостоверений. Azure AD B2C не подписывает запрос, если атрибут WantsSignedRequests в метаданных технического профиля имеет значение false и атрибут WantAuthnRequestsSigned метаданных поставщика удостоверений имеет значение false или не указан.

В следующем примере удалена подпись из запроса SAML.

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

Алгоритм подписи

Azure AD B2C использует Sha1 для подписывания запроса SAML. Используйте метаданные XmlSignatureAlgorithm, чтобы настроить алгоритм для использования. Возможные значения: Sha256, Sha384, Sha512 или Sha1 (по умолчанию). Эти метаданные определяют значение параметра SigAlg (строка запроса или параметр публикации) в запросе SAML. Настройте алгоритм подписи на обеих сторонах, используя одно и то же значение. Используйте только тот алгоритм, который поддерживается вашим сертификатом.

Добавление сведений о ключе

Если поставщик удостоверений указывает, что привязка Azure AD B2C имеет значение HTTP-POST, Azure AD B2C добавляет подпись и алгоритм в текст запроса SAML. Вы также можете настроить идентификатор Microsoft Entra, чтобы включить открытый ключ сертификата, если для привязки задано значение HTTP-POST. Используйте метаданные IncludeKeyInfo в true или false. В следующем примере идентификатор Microsoft Entra не включает открытый ключ сертификата.

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

Настройка идентификатора имени запроса SAML

Элемент запроса авторизации SAML <NameID> указывает формат идентификатора имени SAML. В этом разделе описывается конфигурация, заданная по умолчанию, и настройка элемента идентификатора имени.

Предпочтительное имя пользователя

Во время входа пользователя в систему приложение проверяющей стороны может предложить определенное имя пользователя. Azure AD B2C позволяет отправить поставщику удостоверений SAML предпочитаемое имя пользователя. Элемент InputClaims используется для отправки NameId в Subject запроса авторизации SAML.

Чтобы включить идентификатор имени субъекта в запрос авторизации, добавьте следующий элемент <InputClaims> сразу после <CryptographicKeys>. Параметр PartnerClaimType должен иметь значение subject.

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

В этом примере Azure AD B2C отправляет значение утверждения signInName с NameId в Subject запроса авторизации SAML.

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

Можно использовать утверждения контекста, например {OIDC:LoginHint}, для заполнения значения утверждения.

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

Формат политики идентификатора имени

По умолчанию в запросе авторизации SAML указана политика urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. Этот идентификатор имени указывает, что можно использовать любой тип идентификатора, поддерживаемый поставщиком удостоверений для запрошенного субъекта.

Чтобы изменить это поведение, обратитесь к документации поставщика удостоверений, чтобы узнать, какие политики идентификатора имени поддерживаются. Затем добавьте метаданные NameIdPolicyFormat в соответствующий формат политики. Пример:

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

Следующий запрос авторизации SAML содержит политику идентификатора имени.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

Разрешите создание новых учетных записей

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

По умолчанию Azure AD B2C пропускает свойство AllowCreate. Можно изменить это поведение с помощью метаданных NameIdPolicyAllowCreate. Значение этих метаданных — true или false.

В следующем примере показано, как установить свойство AllowCreateNameIDPolicy на true.

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

В следующем примере демонстрируется запрос авторизации с AllowCreate элемента NameIDPolicy в запросе авторизации.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

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

Вы можете заставить внешний SAML IDP запрашивать у пользователя проверку подлинности путем передачи свойства ForceAuthN в запросе на проверку подлинности SAML. Ваш поставщик удостоверений также должен поддерживать это свойство.

Свойство ForceAuthN является логическим значением true или false. По умолчанию Azure AD B2C устанавливает значение ForceAuthN равным false. Если сеанс сбрасывается (например, с помощью prompt=login в OIDC), то ForceAuthN для параметра устанавливается trueзначение . Установка метаданных ForceAuthN в принудительном true режиме принудительно возвращает значение для всех запросов к внешнему поставщику удостоверений.

В нижеприведенном примере показано, что для свойства ForceAuthN задано значение true:

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

В нижеприведенном примере показано свойство ForceAuthN в запросе авторизации:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

Имя поставщика

При необходимости можно включить атрибут ProviderName в запрос авторизации SAML. Задайте метаданные ProviderName , чтобы включить имя поставщика для всех запросов к внешнему поставщику удостоверений SAML. В нижеприведенном примере показано, что для свойства ProviderName задано значение Contoso app:

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

В нижеприведенном примере показано свойство ProviderName в запросе авторизации:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

Добавление ссылок на класс контекста аутентификации

Запрос авторизации SAML может содержать элемент AuthnContext, указывающий контекст запроса авторизации. Элемент может содержать ссылку на класс контекста проверки подлинности, который сообщает поставщику удостоверений SAML, какой механизм проверки подлинности предоставлять пользователю.

Чтобы настроить ссылки на классы контекста проверки подлинности, добавьте метаданные IncludeAuthnContextClassReferences. В значении укажите одну или несколько ссылок URI, определяющих классы контекста проверки подлинности. Укажите несколько URI в виде списка с разделителями-запятыми. Сведения о поддерживаемых URI AuthnContextClassRef см. в документации поставщика удостоверений.

В следующем примере пользователи могут выполнять вход с помощью имени пользователя и пароля, а также выполнять вход с использованием имени пользователя и пароля в защищенном сеансе (SSL/TLS).

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

Следующий запрос авторизации SAML содержит ссылки на классы контекста проверки подлинности.

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Добавление пользовательских данных в запрос авторизации

При необходимости можно включить элементы расширения сообщений протокола, согласованные как Azure AD B2C, так и поставщиком удостоверений. Расширение представлено в формате XML. Элементы расширения включаются путем добавления XML-данных в элемент CDATA <![CDATA[Your Custom XML]]>. Сведения о поддержке элемента расширений см. в документации к поставщику удостоверений.

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

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

Примечание

В соответствии со спецификацией SAML данные расширения должны быть XML с указанием пространства имен (например, "urn:ext:custom", показанный в примере), и они не должны быть одним из пространств имен, относящихся к SAML.

При использовании расширения сообщений протокола SAML ответ SAML выглядит следующим образом:

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

Требование подписанных ответов SAML

Azure AD B2C требует, чтобы все входящие утверждения были подписаны. Это требование можно удалить, задав для WantsSignedAssertions значение false. Поставщик удостоверений не должен подписывать утверждения в этом случае, но даже если это так, Azure AD B2C не проверяет подпись.

Метаданные WantsSignedAssertions управляют флагом WantAssertionsSigned, который включен в метаданные технического профиля Azure AD B2C, совместно используемого с поставщиком удостоверений.

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Если отключить проверку утверждений, также может понадобиться отключить проверку подписи ответа. Задайте для метаданных ResponsesSigned значение false. Поставщик удостоверений не должен подписывать ответное сообщение SAML в этом случае, но даже если это так, Azure AD B2C не проверяет подпись.

В следующем примере удаляется как сообщение, так и подпись утверждения:

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Требование зашифрованных ответов SAML

Чтобы включить шифрование всех входящих утверждений, задайте метаданные WantsEncryptedAssertions. Если требуется шифрование, поставщик удостоверений использует открытый ключ сертификата шифрования в техническом профиле Azure AD B2C. Azure AD B2C расшифровывает утверждение ответа с помощью закрытой части сертификата шифрования.

Если включить шифрование утверждений, также может понадобиться отключить проверку подписи ответа (дополнительные сведения см. в разделе Требование подписанных ответов SAML).

Если для метаданных WantsEncryptedAssertions задано значение true, метаданные технического профиля Azure AD B2C включают раздел encryption. Поставщик удостоверений считывает метаданные и шифрует утверждение ответа SAML с помощью открытого ключа, указанного в метаданных технического профиля Azure AD B2C.

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

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

Шифрование утверждения ответа SAML:

  1. Создайте ключ политики с уникальным идентификатором. Например, B2C_1A_SAMLEncryptionCert.

  2. Набор CryptographicKeys в техническом профиле SAML. Задайте для StorageReferenceId имя ключа политики, который вы создали на шаге 1. Идентификатор SamlAssertionDecryption указывает на использование криптографического ключа для шифрования и расшифровки утверждения ответа SAML.

    <CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>

  3. Задайте для метаданных технического профиля WantsEncryptedAssertions значение true.

    <Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>

  4. Добавьте в поставщик удостоверений новые метаданные технического профиля Azure AD B2C. В параметре KeyDescriptor свойству use должно быть присвоено значение encryption, содержащее открытый ключ сертификата.

Разрешите использование контекстных утверждений

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

  1. Добавьте тип утверждения в элемент ClaimsSchema в BuildingBlocks.

  2. Добавьте выходное утверждение в коллекцию входных или выходных данных. В следующем примере первое утверждение задает значение поставщика удостоверений. Второе утверждение использует утверждения контекста IP-адреса пользователя.

    <OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>

Отключение единого выхода

При запросе выхода из приложения Azure AD B2C пытается выйти из поставщика удостоверений SAML. Дополнительные сведения см. в разделе Выход из сеанса Azure AD B2C. Чтобы отключить режим единого выхода, задайте для метаданных SingleLogoutEnabled значение false.

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

Протокол отладки SAML

Чтобы настроить и отладить федерацию с поставщиком удостоверений SAML, можно использовать расширение браузера для протокола SAML, например расширение SAML DevTools для Chrome, SAML-tracer для FireFox, Microsoft Edge или IE Средства разработчика.

С помощью этих средств можно проверить интеграцию между Azure AD B2C и поставщиком удостоверений SAML. Пример:

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

Примеры запросов и ответов SAML

Язык разметки заявлений системы безопасности (SAML) — это открытый стандарт для обмена данными проверки подлинности и авторизации между поставщиком удостоверений и поставщиком услуг. Когда служба Azure AD B2C создает федерацию с поставщиком удостоверений SAML, она выступает в качестве поставщика услуг, инициируя запрос SAML к поставщику удостоверений SAML и ожидая ответ SAML.

Успешный ответ SAML содержит утверждения безопасности, которые являются инструкциями внешних поставщиков удостоверений SAML. Azure AD B2C анализирует утверждения и сопоставляет их с утверждениями.

Запрос авторизации

Чтобы запросить проверку подлинности пользователя, Azure AD B2C отправляет AuthnRequest элемент внешнему поставщику удостоверений SAML. Пример SAML 2.0 AuthnRequest должен выглядеть примерно так:

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

Ответ

После успешного завершения запрошенного входа внешний поставщик удостоверений SAML отправляет ответ в конечную точку службы потребителя утверждения B2C Azure AD. Ответ на успешную попытку входа может выглядеть следующим образом:

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Запрос на выход

При запросе выхода из приложения Azure AD B2C пытается выйти из поставщика удостоверений SAML. Azure AD B2C отправляет LogoutRequest внешнему поставщику удостоверений сообщение о том, что сеанс завершен. Ниже приведен пример элемента LogoutRequest .

Значение элемента соответствует значению NameIDNameID пользователя, который выходит из службы. Элемент SessionIndex соответствует атрибуту SessionIndexAuthnStatement в ответе SAML для входа.

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

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

  • Узнайте, как диагностировать проблемы с пользовательскими политиками с помощью Application Insights.