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

Статья
10/16/2023

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

Для начала с помощью селектора Choose a policy type (Выбрать тип политики) выберите тип пользовательской политики. 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, задайте для параметра WantAssertionsSigned поставщика услуг SAML значение true. Если задано значение 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.

Для шифрования утверждения SAML Azure AD B2C использует сертификат открытого ключа поставщика услуг. Открытый ключ должен существовать в конечной точке метаданных приложения 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 (по умолчанию), Aes192, Sha512 или Aes128. Метаданные контролируют значение элемента <EncryptedData> в ответе SAML.

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

Rsa15 алгоритм шифрования с открытым ключом по стандарту RSA (PKCS) версии 1.5 (по умолчанию);
RsaOaep алгоритм шифрования с заполнением для оптимального асимметричного шифрования RSA (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 для обслуживания потока, инициируемого IdP.

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

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

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

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

Чтобы выполнить вход или зарегистрировать пользователя с помощью потока, инициируемого IdP, используйте следующий 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

Вы можете настроить отклонение во времени, применяемое к метке времени ответа SAML NotBefore. Это гарантирует, что если время между двумя платформами не синхронизировано, то утверждение 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 и SamlSSOSessionProvider.

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

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

Следующий запрос проверки подлинности SAML показывает, как задать для атрибута ForceAuthn значение true.

<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-трассировщик для Firefox и средства разработчика для Edge или Internet Explorer.

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

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

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

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