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

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

Обзор

Организациям, использующим Azure AD B2C в качестве решения для управления удостоверениями клиентов и доступом, может потребоваться интеграция с приложениями, прошедшими проверку подлинности с помощью протокола SAML. На следующей схеме показано, как Azure AD B2C служит поставщиком удостоверений (IdP) для достижения единого входа с помощью приложений на основе 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. Он должен иметь возможность отправлять запросы samL AuthN и получать, декодировать и проверять ответы SAML из Azure AD B2C. Приложение SAML также называется приложением проверяющей стороны или поставщиком услуг.
• Общедоступная конечная точка метаданных SAML или XML-документ приложения SAML.
• Клиент Azure AD B2C.

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

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

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

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

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

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

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

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

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

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

Отправка сертификата

Необходимо сохранить сертификат в клиенте 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.

Откройте \TrustFrameworkExtensions.xmlSocialAndLocalAccounts в начальном пакете настраиваемой политики.

<ClaimsProviders> Найдите раздел и добавьте следующий фрагмент XML для реализации генератора ответов SAML:

<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 , возвращенном в ответе SAML из Azure AD B2C. Настройте приложение для принятия того же IssuerUri значения во время проверки ответа SAML.

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

   <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.

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

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

Замените весь <TechnicalProfile> элемент в <RelyingParty> элементе следующим 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 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> именем (идентификатором) политики. Ниже приведен пример:

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

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

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

<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.

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

Предоставление общего доступа к метаданным приложения с помощью Azure AD B2C

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

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

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

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

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

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

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

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

<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:

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

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

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

<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.

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

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

Настройте 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 для <SingleSignOnService> XML-элемента.

• Сертификат: этот сертификат 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-адреса выхода в объекте приложения или сервисного принципала.
• Укажите ключ подписи для проверки запросов доверяющей стороны в объекте приложения или главного участника службы.
• Укажите ключ шифрования токена в объекте приложения или основной службы.
• Укажите вход, инициированный поставщиком удостоверений, где поставщик удостоверений — Azure AD B2C.

Связанный контент

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