Регистрация приложения SAML в Azure AD B2C

Выберите тип политики

Поток пользователя Настраиваемая политика

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

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

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

Обзор

Организациям, использующим Azure AD B2C в качестве решения для управления удостоверениями и доступом клиентов, может потребоваться интеграция с приложениями, выполняющими проверку подлинности с помощью протокола SAML. На следующей схеме показано, как Azure AD B2C выступает в качестве поставщика удостоверений (IDP) для обеспечения единого входа (SSO), используя приложения на основе SAML.

1. Приложение создает запрос SAML AuthN, который отправляется в конечную точку входа SAML для Azure AD B2C.
2. Для проверки подлинности пользователь может использовать локальную учетную запись Azure AD B2C или любой другой федеративный поставщик удостоверений (если настроен).
3. Если пользователь входит в систему с помощью федеративного поставщика удостоверений, в Azure AD B2C отправляется ответ маркера.
4. Azure AD B2C создает утверждение SAML и отправляет его в приложение.

Просмотрите это видео, чтобы узнать, как интегрировать приложения SAML с Azure AD B2C.

Необходимые компоненты

Для сценария, описанного в этой статье, вам понадобится следующее:

• Настраиваемая политика SocialAndLocalAccounts из начального пакета настраиваемых политик. Выполните шаги, описанные в статье Начало работы с настраиваемыми политиками в Azure AD B2C.
• Базовое представление о протоколе SAML и знакомство с реализацией SAML приложения.
• Веб-приложение, настроенное как приложение SAML. У него должна быть возможность отправлять запросы AuthN SAML, а также получать от Azure AD B2C ответы SAML, декодировать их и проверять. Приложение SAML также называется приложением, основанным на утверждениях, или поставщиком услуг.
• Общедоступная конечная точка метаданных приложения SAML или XML-документ.
• Клиент Azure AD B2C.

Если у вас еще нет приложения SAML и связанной конечной точки метаданных, можно использовать специальное приложение SAML, предоставленное для тестирования.

Важно!

Ваши конечные точки должны соответствовать требованиям безопасности Azure AD B2C. Ранние версии и шифры TLS считаются нерекомендуемыми. Дополнительные сведения см. в статье Требования к комплекту шифров и TLS в Azure AD B2C.

Настройка сертификатов

Чтобы создать отношение доверия между приложением и Azure AD B2C, у обеих служб должны быть возможность создавать и проверять подписи друг друга. Настройте сертификаты X509 в приложении и в Azure AD B2C.

Сертификаты приложений

Использование	Обязательное поле	Описание
Подписывание запросов SAML	No	Сертификат с закрытым ключом, хранящимся в вашем веб-приложении. Приложение использует сертификат для подписи запросов SAML, отправляемых в Azure AD B2C. Веб-приложение должно предоставлять открытый ключ, используя свою конечную точку метаданных SAML. Azure AD B2C проверяет подпись запроса SAML с помощью открытого ключа из метаданных приложения.
Шифрование утверждения SAML	No	Сертификат с закрытым ключом, хранящимся в вашем веб-приложении. Веб-приложение должно предоставлять открытый ключ, используя свою конечную точку метаданных SAML. Azure AD B2C может шифровать утверждения для приложения, используя открытый ключ. Приложение использует закрытый ключ для расшифровки утверждения.

Сертификаты Azure AD B2C

Использование	Обязательное поле	Описание
Подписывание ответа SAML	Да	Сертификат с закрытым ключом, хранящимся в Azure AD B2C. Этот сертификат используется в Azure AD B2C для подписи ответа SAML, отправляемого приложению. Приложение считывает открытый ключ метаданных в Azure AD B2C, чтобы проверить подпись ответа SAML.
Подписывание утверждения SAML	Да	Сертификат с закрытым ключом, хранящимся в Azure AD B2C. Этот сертификат используется в Azure AD B2C для подписи части <saml:Assertion> ответа SAML.

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

Создание ключа политики

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

Совет

Этот ключ политики можно использовать для других целей, например для подписания утверждения SAML.

Получение сертификата

Если у вас еще нет сертификата, можно использовать самозаверяющий сертификат. Самозаверяющий сертификат — это сертификат безопасности, не подписанный центром сертификации (ЦС) и не предоставляющий гарантий безопасности сертификата, подписанного центром сертификации.

Windows

В Windows для создания сертификата используется командлет PowerShell New-SelfSignedCertificate.

1. Выполните следующую команду PowerShell, чтобы создать самозаверяющий сертификат. Измените аргумент -Subject, указав реальные значения приложения и имени арендатора Azure  AD B2C, например contosowebapp.contoso.onmicrosoft.com. Можно также скорректировать дату -NotAfter, чтобы указать другой срок действия сертификата.

   PowerShell

   New-SelfSignedCertificate `
       -KeyExportPolicy Exportable `
       -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
       -KeyAlgorithm RSA `
       -KeyLength 2048 `
       -KeyUsage DigitalSignature `
       -NotAfter (Get-Date).AddMonths(12) `
       -CertStoreLocation "Cert:\CurrentUser\My"
   

2. На компьютере Windows найдите элемент Управление сертификатами пользователей и выберите его.

3. В области Сертификаты — текущий пользователь выберите Личное>Сертификаты>имя_приложения.имя_арендатора.onmicrosoft.com.

4. Выберите сертификат, а затем выберите Действие > Все задачи > Экспортировать.

5. Нажмите Далее>Да, экспортировать закрытый ключ>Далее.

6. Примите значения по умолчанию для параметра Формат экспортируемого файла и нажмите кнопку Далее.

7. Включите параметр Пароль, введите пароль для сертификата, а затем нажмите кнопку Далее.

8. Чтобы указать расположение для сохранения сертификата, нажмите кнопку Обзор и перейдите в нужный каталог.

9. В окне Сохранить как введите значение в поле Имя файла и нажмите кнопку Сохранить.

10. Выберите Далее>Готово.

Чтобы служба Azure AD B2C принимала пароль файла с расширением PFX, пароль необходимо зашифровать с помощью TripleDES-SHA1 в служебной программе экспорта хранилища сертификатов Windows, а не с помощью AES256-SHA256.

macOS

В macOS для создания сертификата используйте Помощник по сертификатам в Keychain Access.

1. Следуйте инструкциям по созданию самозаверяющих сертификатов в Keychain Access на Mac.
2. Выберите созданный сертификат в приложении Keychain Access на компьютере Mac.
3. Выберите Файл>Экспорт элементов.
4. Выберите имя файла для сохранения сертификата. Например, self-signed-certificate.p12.
5. Для параметра Формат файла установите значение Обмен персональными данными (.p12).
6. Выберите Сохранить.
7. Введите пароль в полях Пароль и Подтвердить.
8. Замените расширение файла на PFX. Например, self-signed-certificate.pfx.

Загрузка сертификата

Вам необходимо сохранить сертификат в клиенте Azure AD B2C.

1. Войдите на портал Azure.
2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
3. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.
4. На странице Обзор выберите Identity Experience Framework.
5. Выберите Ключи политики, а затем щелкните Добавить.
6. В пункте Параметры выберите Отправить.
7. В поле Имя укажите имя ключа политики. Например, SamlIdpCert. Префикс B2C_1A_ будет автоматически добавлен к имени ключа.
8. Найдите и выберите PFX-файл сертификата с закрытым ключом.
9. Выберите Создать.

Включение политики для подключения с помощью приложения SAML

Чтобы подключиться к приложению SAML, у Azure AD B2C должна быть возможность создавать ответы SAML.

Откройте файл SocialAndLocalAccounts\TrustFrameworkExtensions.xml из начального пакета настраиваемых политик.

Найдите раздел <ClaimsProviders> и добавьте следующий фрагмент XML-кода, чтобы реализовать генератор ответов SAML.

XML

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>

    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
      </CryptographicKeys>
      <InputClaims/>
      <OutputClaims/>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
    </TechnicalProfile>

    <!-- Session management technical profile for SAML-based tokens -->
    <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>

  </TechnicalProfiles>
</ClaimsProvider>

Настройка URI издателя для ответа SAML

Значение элемента IssuerUri метаданных можно изменить в техническом профиле издателя маркера SAML. Это изменение будет отражено в атрибуте issuerUri, возвращенном из Azure AD B2C в ответе SAML. Настройте приложение на прием того же значения IssuerUri во время проверки ответа SAML.

XML

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Настройка политики для выдачи ответа SAML

Теперь, когда политика может создавать ответы SAML, необходимо настроить ее на выдачу приложению ответа SAML вместо ответа JWT по умолчанию.

Создание политики регистрации или входа, настроенной для работы с SAML

1. Создайте копию файла SignUpOrSignin.xml в рабочем каталоге начального пакета и сохраните ее под новым именем. В этой статье для примера используется файл SignUpOrSigninSAML.xml. Он представляет собой файл политики для проверяющей стороны. По умолчанию он настроен на выдачу ответа JWT.

2. Откройте файл SignUpOrSigninSAML.xml в любом удобном редакторе.

3. Измените значение:

   1. PolicyId...B2C_1A_signup_signin_saml

   2. PublicPolicyUri изменено на http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml. Замените <tenant-name> заполнитель поддоменом доменного имени клиента Azure AD B2C. Например, если основной домен клиента — это contoso.onmicrosoft.com, используйте contoso. Если у вас нет имени клиента, узнайте , как прочитать сведения о клиенте.

   XML

   <TrustFrameworkPolicy
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
   PolicySchemaVersion="0.3.0.0"
   TenantId="<tenant-name>.onmicrosoft.com"
   PolicyId="B2C_1A_signup_signin_saml"
   PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">
   

4. В конце пути взаимодействия пользователя Azure AD B2C содержит шаг SendClaims. Этот шаг ссылается на технический профиль издателя маркера. Чтобы выдавать ответ SAML, а не заданный по умолчанию ответ JWT, измените шаг SendClaims, чтобы он ссылался на новый технический профиль издателя маркера SAML — Saml2AssertionIssuer.

Добавьте следующий фрагмент XML-кода перед элементом <RelyingParty>. Этот XML-код перезаписывает шаг 7 оркестрации в пути взаимодействия пользователя SignUpOrSignIn.

Если вы начали из другой папки в начальном пакете или настроили путь взаимодействия пользователя, добавив или удалив шаги оркестрации, убедитесь, что число в элементе order соответствует числу, заданному в пути взаимодействия пользователя для шага издателя маркера. Например, в других папках начального пакета соответствующий шаг будет иметь номер 4 для LocalAccounts, 6 — для SocialAccounts и 9 — для SocialAndLocalAccountsWithMfa.

XML

<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>
      <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

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

Замените весь элемент <TechnicalProfile> в элементе <RelyingParty> следующим XML-кодом технического профиля.

XML

    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>

Окончательный файл политики для проверяющей стороны должен выглядеть подобно приведенному ниже XML-коду.

XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="contoso.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin_saml"
  PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">

  <BasePolicy>
    <TenantId>contoso.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <UserJourneys>
    <UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

Примечание

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

Отправка политики

Сохраните изменения и отправьте новые файлы политики TrustFrameworkExtensions.xml и SignUpOrSigninSAML.xml на портал Azure.

Проверка метаданных SAML для IdP Azure AD B2C

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

Метаданные политики Azure AD B2C доступны по следующему URL-адресу.

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

Замените <tenant-name> именем вашего клиента Azure AD B2C. Замените <policy-name> именем (ID) политики. Приведем пример:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Регистрация приложения SAML в Azure AD B2C

Чтобы служба Azure AD B2C доверяла приложению, вы создаете регистрацию приложения Azure AD B2C. Эта регистрация содержит сведения о конфигурации, такие как конечная точка метаданных приложения.

1. Войдите на портал Azure.
2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
3. В меню слева щелкните Azure AD B2C. Либо выберите Все службы, а затем найдите и выберите Azure AD B2C.
4. Щелкните Регистрация приложений и выберите Новая регистрация.
5. Введите имя приложения. Например, SAMLApp1.
6. В разделе Поддерживаемые типы учетных записей выберите Учетные записи только в этом каталоге организации.
7. В разделе URI перенаправления выберите Интернет и введите https://localhost. Это значение можно изменить позже в манифесте регистрации приложения.
8. Выберите Зарегистрировать.

Настройка приложения в Azure AD B2C

Для приложений SAML необходимо настроить несколько свойств в манифесте регистрации приложения.

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

Добавление идентификатора

Когда приложение SAML выполняет запрос к Azure AD B2C, запрос AuthN SAML включает атрибут Issuer. Значение этого атрибута обычно совпадает со значением entityID метаданных приложения. В Azure AD B2C это значение используется для поиска регистрации приложения в каталоге и чтения конфигурации. Для успешного поиска для identifierUri в регистрации приложения должно быть установлено значение, соответствующее атрибуту Issuer.

В манифесте регистрации найдите параметр identifierURIs и добавьте соответствующее значение. Это значение будет совпадать со значением, настроенным в запросах AuthN SAML для EntityId в приложении, и значением entityID в метаданных приложения. Вам также потребуется найти accessTokenAcceptedVersion параметр и задать для параметра значение 2.

Важно!

Если не обновить accessTokenAcceptedVersion до 2, появится сообщение об ошибке, в котором требуется проверенный домен.

В следующем примере показано значение entityID в метаданных SAML.

XML

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

Свойство identifierUris будет принимать только URL-адреса из домена tenant-name.onmicrosoft.com.

JSON

"identifierUris":"https://tenant-name.onmicrosoft.com/app-name",

Совместное использование метаданных приложения с Azure AD B2C

После загрузки регистрации приложения с помощью соответствующего значения identifierUri Azure AD B2C использует метаданные приложения, чтобы проверить запрос AuthN SAML и определить способ реагирования.

Желательно, чтобы ваше приложение предоставляло общедоступную конечную точку метаданных.

Если есть свойства, указанные одновременно в URL-адресе метаданных SAML и в манифесте регистрации приложения, они объединяются. Свойства, указанные в URL-адресе метаданных, обрабатываются первыми и имеют приоритет.

Используя в качестве примера тестовое приложение SAML, для samlMetadataUrl в манифесте приложения можно использовать следующее значение.

JSON

"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",

Переопределение или задание URL-адреса потребителя утверждений (необязательно)

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

URL-адрес ответа для приложения SAML — это конечная точка, в которой приложение ожидает получения ответов SAML. Приложение обычно предоставляет этот URL-адрес в документе метаданных в качестве атрибута Location элемента AssertionConsumerService, как показано в этом примере:

XML

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer" />        
</SPSSODescriptor>

Если элемент AssertionConsumerService метаданных приложения отсутствует или его нужно переопределить, настройте свойство replyUrlsWithType манифеста регистрации приложения. Azure AD B2C использует replyUrlsWithType для перенаправления пользователей после входа по типу привязки HTTP-POST.

Используя в качестве примера тестовое приложение SAML, установите для свойства url в replyUrlsWithType значение, показанное в следующем фрагменте кода JSON.

JSON

"replyUrlsWithType":[
  {
    "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
    "type":"Web"
  }
],

Переопределите или задайте URL-адрес выхода (необязательно)

URL-адрес выхода определяет, где перенаправлять пользователя после запроса на выход. Приложение обычно предоставляет этот URL-адрес в документе метаданных в качестве атрибута Location элемента SingleLogoutService, как показано в следующем примере:

XML

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://samltestapp2.azurewebsites.net/logout" ResponseLocation="https://samltestapp2.azurewebsites.net/logout" />

</SPSSODescriptor>

Если элемент SingleLogoutService метаданных приложения отсутствует, настройте свойство logoutUrl манифеста регистрации приложения. Azure AD B2C использует logoutURL для перенаправления пользователей после выхода по типу привязки HTTP-Redirect.

Используя тестовое приложение SAML в качестве примера, задайте для свойства logoutUrl значение https://samltestapp2.azurewebsites.net/logout:

JSON

"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",

Примечание

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

Настройка Azure AD B2C в качестве поставщика удостоверений SAML в приложении SAML

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

Метаданные в приложении можно настроить как статические метаданные или динамические метаданные. В статическом режиме скопируйте все метаданные или их часть из метаданных политики Azure AD B2C. В динамическом режиме укажите URL-адрес в метаданных и разрешите приложению динамически считывать метаданные.

Обычно требуются некоторые или все перечисленные ниже параметры.

• Метаданные. Используйте формат https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata.

• Издатель. Значение issuer запроса SAML должно совпадать с одним из URI, настроенных в элементе identifierUris манифеста регистрации приложения. Если имя issuer запроса SAML отсутствует в элементе identifierUris, добавьте его в манифест регистрации приложения. Например: https://contoso.onmicrosoft.com/app-name.

• URL-адрес входа, конечная точка SAML, URL-адрес SAML. Проверьте значение в файле метаданных политики SAML Azure AD B2C для XML-элемента <SingleSignOnService>.

• Сертификат. Это B2C_1A_SamlIdpCert, но без закрытого ключа. Чтобы получить открытый ключ сертификата, выполните следующие действия.

  1. Перейдите по URL-адресу метаданных, указанному ранее.
  2. Скопируйте значение в элемент <X509Certificate>.
  3. Вставьте его в текстовый файл.
  4. Сохраните текстовый файл под именем .cer.

Тестирование с использованием приложения для тестирования SAML

Для тестирования конфигурации можно использовать наше тестовое приложение SAML.

• Измените имя клиента.
• Обновите имя политики. Например, B2C_1A_signup_signin_saml.
• Укажите URI издателя. Используйте один из URI, найденных в элементе identifierUris манифеста регистрации приложения. Например, укажите https://contoso.onmicrosoft.com/app-name.

Щелкните Вход, и появится экран входа пользователя. После входа ответ SAML будет отправлен обратно в пример приложения.

Поддерживаемые и неподдерживаемые модальности SAML

Следующие сценарии приложения SAML поддерживаются с помощью вашей собственной конечной точки метаданных.

• Укажите несколько URL-адресов выхода или привязку POST для URL-адреса выхода в объекте приложения или субъекта-службы.
• Укажите ключ для подписи, чтобы проверить запросы проверяющей стороны в объекте приложения или субъекта-службы.
• Задайте ключ шифрования маркера в объекте приложения или субъекта-службы.
• Определите вход в систему, инициируемый поставщиком удостоверений (IdP), которым является Azure AD B2C.

Следующие шаги

• Скачайте тестовое веб-приложение SAML из репозитория сообщества Azure AD B2C GitHub.
• См. статью о параметрах регистрации приложения SAML в Azure AD B2C.
• Узнайте, как создать устойчивость с помощью рекомендаций разработчика.