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

Эта функция доступна только для пользовательских политик. Для действий по настройке выберите пользовательскую политику в предыдущем селекторе.

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

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

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

Элемент выходного утверждения содержит следующие атрибуты:

• 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">[email protected]</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>

Assertion consumer service

Служба потребителя утверждений (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-файле приведен пример элемента службы потребительского сервиса "Метаданные утверждения политики Azure AD B2C".

<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 (строка запроса или параметр post) опускаются в запросе.

Эти метаданные также управляют атрибутом 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 ID для включения открытого ключа сертификата, если для привязки задано значение HTTP-POST. Используйте метаданные IncludeKeyInfo для true, или false. В следующем примере идентификатор Microsoft Entra не включает открытый ключ сертификата.

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

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

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

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

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

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

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

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

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>[email protected]</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>

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

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

Чтобы изменить это поведение, обратитесь к документации поставщика удостоверений, чтобы узнать, какие политики идентификаторов имен поддерживаются. Затем добавьте 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.

В следующем примере показано, как задать AllowCreate свойство NameIDPolicy для 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 запрашивать у пользователя запрос на проверку подлинности, передав свойство ForceAuthN в запросе проверки подлинности SAML. Поставщик удостоверений также должен поддерживать это свойство.

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

В следующем примере показано свойство, 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[Your Custom XML]]>CDATA. Сведения о поддержке элемента расширений см. в документации к поставщику удостоверений.

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

<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 ответ 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 управляют флагом метаданных SAML 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 включают раздел шифрования . Поставщик удостоверений считывает метаданные и шифрует утверждение ответа 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. В вашем техническом профиле SAML коллекция CryptographicKeys . Задайте для StorageReferenceId имя ключа политики, созданного на первом шаге. Идентификатор 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 или средства разработчика Internet Explorer.

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

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

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

Security Assertion Markup Language (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 отправляет ответ в конечную точку потребительской службы утверждения Azure AD B2C. Ответ на успешную попытку входа выглядит следующим образом:

<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>[email protected]</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 элемента.

Значение элемента совпадает NameID со значением NameID пользователя, из которого выполняется выход. Элемент SessionIndex соответствует SessionIndex атрибуту of AuthnStatement в ответе 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.