Добавление AD FS в качестве поставщика удостоверений SAML с помощью пользовательских политик в Azure Active Directory B2C

Мақала
06/01/2023

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

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

Примечание.

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

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

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

Выполните шаги, описанные в статье Начало работы с настраиваемыми политиками в Azure Active Directory B2C.
Если вы еще этого не сделали, зарегистрируйте веб-приложение.

Создание самозаверяющего сертификата

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

Windows
macOS

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

Выполните следующую команду PowerShell, чтобы создать самозаверяющий сертификат. Измените аргумент -Subject, указав реальные значения приложения и имени арендатора Azure AD B2C, например contosowebapp.contoso.onmicrosoft.com. Можно также скорректировать дату -NotAfter, чтобы указать другой срок действия сертификата.
```
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"
```
На компьютере Windows найдите элемент Управление сертификатами пользователей и выберите его.
В области Сертификаты — текущий пользователь выберите Личное>Сертификаты>имя_приложения.имя_арендатора.onmicrosoft.com.
Выберите сертификат, а затем выберите Действие >Все задачи >Экспортировать.
Нажмите Далее>Да, экспортировать закрытый ключ>Далее.
Примите значения по умолчанию для параметра Формат экспортируемого файла и нажмите кнопку Далее.
Включите параметр Пароль, введите пароль для сертификата, а затем нажмите кнопку Далее.
Чтобы указать расположение для сохранения сертификата, нажмите кнопку Обзор и перейдите в нужный каталог.
В окне Сохранить как введите значение в поле Имя файла и нажмите кнопку Сохранить.
Выберите Далее>Готово.

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

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

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

Войдите на портал Azure.
Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.
На странице "Обзор" выберите Identity Experience Framework.
Выберите Ключи политики, а затем щелкните Добавить.
Для пункта Параметры выберите Upload.
Введите имя ключа политики. Например, SAMLSigningCert. Префикс B2C_1A_ будет автоматически добавлен к имени ключа.
Найдите и выберите PFX-файл сертификата с закрытым ключом.
Нажмите кнопку Создать.

Добавление поставщика утверждений

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

Чтобы определить учетную запись AD FS в качестве поставщика утверждений, добавьте ее в элемент ClaimsProviders в файле расширения политики. Дополнительные сведения см. в разделе об определении поставщика удостоверений SAML.

Откройте файл TrustFrameworkExtensions.xml.
Найдите элемент ClaimsProviders. Если он не существует, добавьте его в корневой элемент.

Добавьте новый элемент ClaimsProvider следующим образом.

<ClaimsProvider>
  <Domain>contoso.com</Domain>
  <DisplayName>Contoso</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Contoso-SAML2">
      <DisplayName>Contoso</DisplayName>
      <Description>Login with your AD FS account</Description>
      <Protocol Name="SAML2"/>
      <Metadata>
        <Item Key="WantsEncryptedAssertions">false</Item>
        <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="userPrincipalName" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/>
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication"/>
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Замените your-AD-FS-domain именем своего домена AD FS и замените значение исходящего утверждения identityProvider своим DNS (произвольное значение, указывающее домен).

Откройте раздел <ClaimsProviders> и добавьте следующий фрагмент кода XML. Если политика уже содержит технический профиль SM-Saml-idp, перейдите к следующему шагу. Дополнительные сведения см. в разделе об управлении сеансом единого входа.

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-Saml-idp">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IncludeSessionIndex">false</Item>
        <Item Key="RegisterServiceProviders">false</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Сохраните файл.

Добавление пути взаимодействия пользователя

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

Откройте файл TrustFrameworkBase.xml из начального пакета.
Найдите и скопируйте все содержимое элемента UserJourney, в котором присутствует запись Id="SignUpOrSignIn".
Откройте файл TrustFrameworkExtensions.xml и найдите элемент UserJourneys. Если элемент не существует, добавьте его.
Вставьте все скопированное содержимое элемента UserJourney в качестве дочернего элемента в элемент UserJourneys.
Переименуйте идентификатор этого пути взаимодействия пользователя. Например, Id="CustomSignUpSignIn".

Добавление поставщика удостоверений в путь взаимодействия пользователя

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

В пути взаимодействия пользователя найдите элемент шага оркестрации, включающий Type="CombinedSignInAndSignUp" или Type="ClaimsProviderSelection". Обычно это первый шаг оркестрации. Элемент ClaimsProviderSelections содержит список поставщиков удостоверений, которые пользователь может использовать для входа. Порядок элементов управляет порядком кнопок входа, представленных пользователем. Добавьте XML-элемент ClaimsProviderSelection. Присвойте значению TargetClaimsExchangeId понятное имя.
На следующем шаге оркестрации добавьте элемент ClaimsExchange. Задайте в качестве Id значение идентификатора обмена утверждениями целевого объекта. Замените значение TechnicalProfileReferenceId идентификатором технического профиля, созданным ранее.

В следующем коде XML показаны первые два этапа оркестрации пути взаимодействия пользователя с поставщиком удостоверений:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
  </ClaimsExchanges>
</OrchestrationStep>

Настройка политики проверяющей стороны

Политика проверяющей стороны, например SignUpSignIn.xml, указывает путь взаимодействия пользователя, который будет исполнять Azure AD B2C. Найдите элемент DefaultUserJourney в элементе проверяющей стороны. Обновите ReferenceId в соответствии с идентификатором пути взаимодействия пользователя, в который добавлен поставщик удостоверений.

В следующем примере в качестве значения параметра ReferenceId пути взаимодействия пользователя CustomSignUpSignIn задано CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Передача настраиваемой политики

Войдите на портал Azure.
Выберите значок Каталог и подписка в верхней панели инструментов портала, а затем выберите каталог, содержащий клиент Azure AD B2C.
В портале Azure найдите и выберите Azure AD B2C.
В разделе Политики выберите Identity Experience Framework.
Выберите Отправить пользовательскую политику, а затем отправьте два измененных файла политики в следующем порядке: политика расширения, например TrustFrameworkExtensions.xml, а затем политика проверяющей стороны, например SignUpSignIn.xml.

Настройка отношения доверия с проверяющей стороной AD FS

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

https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/your-policy/samlp/metadata?idptp=your-technical-profile

При использовании личного домена используйте следующий формат:

https://your-domain-name/your-tenant-name.onmicrosoft.com/your-policy/samlp/metadata?idptp=your-technical-profile

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

your-tenant-name — именем собственного клиента, например your-tenant.onmicrosoft.com.
your-domain-name — именем личного домена, например login.contoso.com.
your-policy — именем собственной политики. Например, B2C_1A_signup_signin_adfs.
your-technical-profile — именем технического профиля поставщика удостоверений SAML. Например, Contoso-SAML2.

Откройте браузер и перейдите по URL-адресу. Убедитесь, что ввели правильный URL-адрес и что имеете доступ к XML-файлу метаданных. Чтобы добавить новое отношение доверия с проверяющей стороной с помощью оснастки управления AD FS и вручную настроить параметры, выполните следующую процедуру на сервере федерации. Для этого необходимо по крайней мере входить в группу Администраторы или аналогичную группу на локальном компьютере.

В диспетчере серверов выберите Инструменты, затем выберите Управление AD FS.
Выберите Добавить отношение доверия с проверяющей стороной.
На странице приветствия выберите Поддерживающие утверждения и нажмите кнопку Запустить.
На странице Выбор источника данных выберите параметр Импорт данных о проверяющей стороне, опубликованных в Интернете или локальной сети, укажите URL-адрес метаданных Azure AD B2C и нажмите кнопку Далее.
На странице Указание отображаемого имени введите отображаемое имя. В поле Примечания введите описание для этого отношения доверия с проверяющей стороной и нажмите кнопку Далее.
На странице Выбор политики управления доступом выберите политику и нажмите кнопку Далее.
На странице Готовность для добавления отношения доверия проверьте параметры и нажмите кнопку Далее, чтобы сохранить сведения об отношении доверия с проверяющей стороной.
На странице Готово щелкните Закрыть. При этом автоматически откроется диалоговое окно Изменить правила утверждений.
Выберите Добавить правило.
В разделе Claim rule template (Шаблон правила утверждения) выберите Send LDAP attributes as claims (Отправка атрибутов LDAP как утверждений).

Укажите имя правила утверждения. В разделе Хранилище атрибутов выберите Active Directory, добавьте приведенные ниже утверждения, а затем нажмите кнопки Готово и ОК.

Атрибут LDAP	Тип исходящего утверждения
Имя субъекта-пользователя	userPrincipalName
Surname	family_name
Given-Name	given_name
E-Mail-Address	эл. почта
Display-Name	name

Обратите внимание, что некоторые имена не отображаются в раскрывающемся списке типов исходящего утверждения. Их необходимо ввести вручную. (Раскрывающийся список можно редактировать.)

В зависимости от типа сертификата может потребоваться задать хэш-алгоритм. В окне свойств отношения доверия с проверяющей стороной (демоверсия B2C) перейдите на вкладку Дополнительно, измените алгоритм SHA на SHA-256 и нажмите кнопку ОК.
В диспетчере серверов выберите Инструменты, затем выберите Управление AD FS.
Выберите созданное отношение доверия проверяющей стороны, щелкните Обновить с использованием метаданных федерации, а затем выберите Обновить.

Тестирование настраиваемой политики

Войдите на портал Azure.
Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
В портале Azure найдите и выберите Azure AD B2C.
В разделе Политики выберите Identity Experience Framework.
Выберите политику проверяющей стороны, например B2C_1A_signup_signin.
В разделе Приложение выберите зарегистрированное ранее веб-приложение. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
Нажмите кнопку Выполнить.
На странице регистрации или входа выберите Contoso AD FS для входа с помощью поставщика удостоверений Contoso AD FS.

Если вход выполнен успешно, в браузере откроется страница https://jwt.ms с содержимым маркера, возвращенного Azure AD B2C.

Устранение неполадок службы AD FS

AD FS настроен для использования журнала приложений Windows. При возникновении проблем с настройкой AD FS в качестве поставщика удостоверений SAML с помощью пользовательских политик в Azure AD B2C может потребоваться проверить журнал событий AD FS:

На панели поиска Windows введите средство просмотра событий, а затем выберите классическое приложение Просмотр событий.
Чтобы просмотреть журнал с другого компьютера, щелкните правой кнопкой мыши элемент Просмотр событий (локальных). Выберите пункт Подключение к другому компьютеру и заполните поля в диалоговом окне Выбор компьютера.
В средстве просмотра событий откройте журналы приложений и служб.
Выберите AD FS, а затем — Администратор.
Чтобы просмотреть дополнительные сведения о событии, дважды щелкните событие.

Запрос SAML не подписан с ожидаемым событием алгоритма подписи

Эта ошибка означает, что запрос SAML, отправленный Azure AD B2C, не подписан с использованием ожидаемого алгоритма подписи, настроенного в AD FS. Например, запрос SAML подписан с помощью алгоритма подписи rsa-sha256, но ожидается использование алгоритма rsa-sha1. Чтобы устранить эту проблему, убедитесь, что для и в Azure AD B2C, и в AD FS настроен один и тот же алгоритм подписи.

Вариант 1. Задание алгоритма подписи в Azure AD B2C

Можно настроить способ подписи запроса SAML в Azure AD B2C. Метаданные XmlSignatureAlgorithm определяют значение параметра SigAlg (строка запроса или параметр отправки) в запросе SAML. В следующем примере Azure AD B2C настраивается для использования алгоритма подписи rsa-sha256.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>

Вариант 2. Задание алгоритма подписи в AD FS

Можно также настроить ожидаемый алгоритм подписи запроса SAML в AD FS.

В диспетчере серверов выберите Инструменты, затем выберите Управление AD FS.
Выберите ранее созданное отношение доверия с проверяющей стороной.
Нажмите Свойства, а затем выберите Дополнительно.
Настройте защищенный хэш-алгоритм и нажмите кнопку ОК, чтобы сохранить изменения.

Запрос на перенаправление HTTP не содержит нужный параметр "Подпись" для подписанного запроса (AADB2C90168)

Вариант 1. Задание значения "false" для ResponsesSigned в Azure AD B2C

Можно отключить требование подписанного сообщения в Azure AD B2C. В следующем примере описана настройка Azure AD B2C, при которой для подписанного запроса не требуется параметр "Подпись".

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Вариант 2. Задание проверяющей стороны в AD FS для подписи сообщения и утверждения

Можно также настроить проверяющую сторону в AD FS, как описано ниже:

Откройте PowerShell от имени администратора и запустите командлет Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion, чтобы подписать сообщение и утверждение.
Запустите Set-AdfsRelyingPartyTrust -TargetName <RP Name> и убедитесь, что свойству SamlResponseSignature задано значение MessageAndAssertion.

Бөлісу құралы: