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

2025-05-02

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

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

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

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

Укажите подпись ответа SAML

Вы можете указать сертификат, который будет использоваться для подписи сообщений SAML. Сообщение — это элемент в ответе <samlp:Response> SAML, отправляемый приложению.

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

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

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

Вы можете настроить алгоритм подписи, используемый для подписи утверждения SAML. Возможные значения: Sha256, Sha384, Sha512 или Sha1. Убедитесь, что технический профиль и приложение используют тот же алгоритм подписи. Используйте только тот алгоритм, который поддерживается вашим сертификатом.

Настройте алгоритм подписи с помощью XmlSignatureAlgorithm ключа метаданных в элементе доверяющей стороны Metadata.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="XmlSignatureAlgorithm">Sha256</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Проверьте подпись утверждения SAML

Когда приложение ожидает, что раздел утверждения SAML будет подписан, убедитесь, что поставщик служб SAML задал значение WantAssertionsSignedtrue. Если задано false значение или не существует, раздел утверждения не будет подписан.

В следующем примере показаны метаданные для поставщика служб SAML, где WantAssertionsSigned установлено на true.

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

Сертификат подписи

Политика должна указать сертификат, который будет использоваться для подписи утверждений SAML в ответе SAML. Если у вас еще нет ключа политики, создайте его. Затем настройте SamlAssertionSigning элемент метаданных в техническом профиле издателя токенов SAML. StorageReferenceId должен ссылаться на название ключа политики.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Включение шифрования в утверждениях SAML

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

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

<KeyDescriptor use="encryption">
  <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
    <X509Data>
      <X509Certificate>valid certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
</KeyDescriptor>

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

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Метод шифрования

Чтобы настроить метод шифрования, используемый для зашифровки данных утверждения SAML, задайте ключ метаданных DataEncryptionMethod в доверяющей стороне. Возможные значения: Aes256 (по умолчанию), Aes192Sha512, или Aes128. Метаданные контролируют значение элемента <EncryptedData> в ответе SAML.

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

Rsa15 (по умолчанию): алгоритм шифрования открытого ключа RSA (PKCS) версии 1.5.
RsaOaep: Алгоритм шифрования с оптимальным асимметричным шифрующим дополнением (OAEP).

Метаданные контролируют значение элемента <EncryptedKey> в ответе SAML.

В следующем примере показан EncryptedAssertion раздел утверждения SAML. Метод шифрования данных — Aes128, и метод шифрования ключа — Rsa15.

<saml:EncryptedAssertion>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <dsig:KeyInfo>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAssertion>

Формат зашифрованных утверждений можно изменить. Чтобы настроить формат шифрования, установите ключ метаданных UseDetachedKeys в доверяющей стороне. Возможные значения: true или false (по умолчанию). Если задано значение true, отсоединяемые ключи добавляют зашифрованное утверждение как дочерний элемент EncryptedAssertion вместо EncryptedData.

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

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="DataEncryptionMethod">Aes128</Item>
      <Item Key="KeyEncryptionMethod">Rsa15</Item>
      <Item Key="UseDetachedKeys">false</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Настройка потока, инициированного поставщиком удостоверений

Когда приложение ожидает получения утверждения SAML, не отправляя запрос SAML AuthN поставщику удостоверений (IdP), необходимо настроить Azure AD B2C для потока, инициированного поставщиком удостоверений.

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

Сейчас мы не поддерживаем сценарии, в которых инициирующий поставщик удостоверений является внешним поставщиком удостоверений, федеративным с Azure AD B2C, такими как службы федерации Active Directory или Salesforce. Поток, инициированный поставщиком идентификации, поддерживается только для аутентификации локальной учетной записи в Azure AD B2C.

Чтобы включить поток, инициированный IdP, задайте элемент IdpInitiatedProfileEnabled метаданных true в техническом профиле проверяющей стороны.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="IdpInitiatedProfileEnabled">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Для входа или регистрации пользователя через поток, инициированный провайдером аутентификации, используйте следующий URL-адрес:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state>

Замените следующие значения:

Замените <tenant-name> именем своего клиента.
Замените <policy-name> именем политики проверяющей стороны SAML.
Замените <app-identifier-uri>identifierUris значением в файле метаданных, например https://contoso.onmicrosoft.com/app-name.
[Необязательно] замените <relay-state> значением, включенным в запрос авторизации, который также возвращается в ответе токена. Этот relay-state параметр используется для кодирования сведений о состоянии пользователя в приложении до того, как произошел запрос проверки подлинности, например страницы, на которой они находились.

Пример политики

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

Скачайте пример политики входа, инициированной SAML-SP.
Обновите TenantId, чтобы соответствовать имени арендатора. В этой статье используется пример contoso.b2clogin.com.
Сохраните имя политики B2C_1A_signup_signin_saml.

Настройка времени существования ответа SAML

Вы можете настроить период времени, в течение времени, когда ответ SAML остается допустимым. Задайте время существования с помощью TokenLifeTimeInSeconds элемента метаданных в техническом профиле издателя токенов SAML. Это значение представляет количество секунд, которое может пройти с момента NotBefore метки времени, рассчитанной во время выдачи маркера. Время существования по умолчанию составляет 300 секунд (пять минут).

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenLifeTimeInSeconds">400</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Настройте временное смещение ответа SAML

Вы можете настроить временной сдвиг, применяемый к метке времени ответа NotBefore SAML. Эта конфигурация гарантирует, что если время между двумя платформами не синхронизировано, утверждение SAML по-прежнему считается допустимым, когда оно попадает в этот временной разброс.

Задайте временное отклонение с помощью TokenNotBeforeSkewInSeconds элемента метаданных в техническом профиле издателя токенов SAML. Значение отклонений присваивается в секундах с значением по умолчанию 0. Максимальное значение по — 3600 (один час).

Например, если TokenNotBeforeSkewInSeconds задано значение 120 секунд:

Токен выдан в 13:05:10 UTC.
Маркер действителен с 13:03:10 UTC.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Удаление миллисекунд из даты и времени

Можно указать, будут ли миллисекунда удалены из значений даты и времени в ответе SAML. (К этим значениям относятся IssueInstant, NotBefore, NotOnOrAfter и AuthnInstant.) Чтобы удалить миллисекунды, задайте ключ метаданных RemoveMillisecondsFromDateTime у доверяющей стороны. Возможные значения: false (по умолчанию) или true.

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
        <Item Key="RemoveMillisecondsFromDateTime">true</Item>
      </Metadata>
      <OutputClaims>
             ...
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
    </TechnicalProfile>
  </RelyingParty>

Используйте идентификатор издателя для переопределения URI издателя

Если у вас несколько приложений SAML, зависящих от разных entityID значений, можно переопределить IssuerUri значение в файле проверяющей стороны. Чтобы переопределить URI издателя, скопируйте технический профиль с идентификатором Saml2AssertionIssuer из базового файла и переопределите значение IssuerUri.

Подсказка

Скопируйте раздел <ClaimsProviders> из базы и сохраните эти элементы в поставщике утверждений: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer">, и <DisplayName>Token Issuer</DisplayName>.

Пример:

   <ClaimsProviders>   
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Saml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Metadata>
            <Item Key="IssuerUri">customURI</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
  </ClaimsProviders>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpInSAML" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
     …

Управление сеансом

Вы можете управлять сеансом между Azure AD B2C и приложением проверяющей стороны SAML с помощью UseTechnicalProfileForSessionManagement элемента и SamlSOSOSessionProvider.

Принудить пользователей повторно пройти аутентификацию

Чтобы принудительно выполнить проверку подлинности пользователей, приложение может включить ForceAuthn атрибут в запрос проверки подлинности SAML. Атрибут ForceAuthn является логическим значением. Если задано значение true, сеанс пользователя будет аннулирован в Azure AD B2C, и пользователю потребуется повторно пройти аутентификацию.

В следующем запросе проверки подлинности SAML показано, как задать для атрибута значение ForceAuthntrue.

<samlp:AuthnRequest 
       Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
       ForceAuthn="true" ...>
    ...
</samlp:AuthnRequest>

Подпишите метаданные SAML провайдера удостоверений Azure AD B2C

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

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Отладка протокола SAML

Чтобы настроить и отладить интеграцию с поставщиком услуг, можно использовать расширение браузера для протокола SAML. Расширения браузера включают расширение SAML DevTools для Chrome, SAML-tracer для Firefox и средства разработчика для Edge или Internet Explorer.

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

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

Дальнейшие шаги

Дополнительные сведения о протоколе SAML на веб-сайте OASIS.
Получите тестовое веб-приложение SAML из репозитория сообщества Azure AD B2C GitHub.