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


Настройка регистрации и входа с помощью поставщика удостоверений SAML с использованием Azure Active Directory B2C

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

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

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

Обзор сценария

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

  1. Приложение инициирует запрос авторизации для Azure AD B2C. Приложение может быть приложением OAuth 2.0 или OpenID Connect или поставщиком службы SAML.
  2. На странице входа Azure AD B2C пользователь выбирает вход с использованием учетной записи поставщика удостоверений SAML (например, Contoso). Azure AD B2C инициирует запрос авторизации SAML и выполняет вход в поставщик удостоверений SAML для завершения входа.
  3. Поставщик удостоверений SAML возвращает ответ SAML.
  4. Azure AD B2C проверяет маркер SAML, извлекает утверждения, выпускает свой собственный маркер и переводит пользователя в приложение.

Sign in with SAML identity provider flow

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

Компоненты решения

Для этого сценария необходимы следующие компоненты:

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

Важно!

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

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

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

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

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

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

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

  1. Выполните следующую команду 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"
    
  2. На компьютере Windows найдите элемент Управление сертификатами пользователей и выберите его.

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

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

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

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

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

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

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

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

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

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

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

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

Настройка технического профиля SAML

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

  1. Откройте файл TrustFrameworkExtensions.xml.

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

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

    <ClaimsProvider>
      <Domain>Contoso.com</Domain>
      <DisplayName>Contoso</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Contoso-SAML2">
          <DisplayName>Contoso</DisplayName>
          <Description>Login with your SAML identity provider account</Description>
          <Protocol Name="SAML2"/>
          <Metadata>
            <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="assertionSubjectName" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="http://schemas.microsoft.com/identity/claims/displayname" />
            <OutputClaim ClaimTypeReferenceId="email"  />
            <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>
    

Обновите следующие XML-элементы с помощью соответствующего значения:

XML-элемент Значение
ClaimsProvider\Domain Доменное имя, используемое для прямого входа. Введите доменное имя, которое будет использоваться при прямом входе. Например, contoso.com.
TechnicalProfile\DisplayName Это значение будет отображаться на кнопке входа на экране входа в систему. (например, Contoso).
Metadata\PartnerEntity URL-адрес метаданных поставщика удостоверений SAML. Или скопируйте метаданные поставщика удостоверений и добавьте их в элемент CDATA <![CDATA[Your IDP metadata]]>.

Сопоставьте утверждения.

Элемент OutputClaims содержит список утверждений, возвращаемых поставщиком удостоверений SAML. Возможно, потребуется сопоставить имя утверждения, определенное в вашей политике, с именем утверждения, определенным у поставщика удостоверений. В поставщике удостоверений проверьте список утверждений (проверочных утверждений). Дополнительные сведения см. в разделе Назначение политики сопоставления утверждений.

В приведенном выше примере Contoso-SAML2 содержит утверждения, возвращенные поставщиком удостоверений SAML:

  • Утверждение claimSubjectName сопоставляется с утверждением issuerUserId .
  • Утверждение first_name сопоставляется с утверждением givenName.
  • Утверждение last_name сопоставляется с утверждением surname.
  • Утверждение http://schemas.microsoft.com/identity/claims/displayname сопоставляется с утверждением displayName .
  • Утверждение email не сопоставляется с именем.

Технический профиль также возвращает утверждения, которые не возвращаются поставщиком удостоверений:

  • Утверждение IdentityProvider, содержащее имя поставщика удостоверений.
  • утверждение AuthenticationSource со значением по умолчанию socialIdpAuthentication.

Добавление технического профиля сеанса SAML

Если у вас еще нет технического профиля для сеанса SAML SM-Saml-idp, добавьте его в политику расширения. Откройте раздел <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>

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

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

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

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

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

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

  2. На следующем шаге оркестрации добавьте элемент 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>

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

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

Настройка поставщика удостоверений SAML

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

Процедуры настройки поставщика услуг для разных поставщиков удостоверений SAML различны. Некоторые поставщики удостоверений 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-файлу метаданных.

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

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

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

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