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


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

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

OpenID Connect — это протокол проверки подлинности на основе OAuth 2.0, который может использоваться для безопасного входа пользователей. Azure AD B2C поддерживает большинство поставщиков удостоверений, использующих этот протокол.

В этой статье объясняется, как можно добавить пользовательских поставщиков удостоверений OpenID Connect в потоки пользователя.

Важно!

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

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

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

  1. Войдите на портал Azure с правами глобального администратора клиента Azure AD B2C.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
  3. Выберите Все службы в левом верхнем углу окна портала Azure, найдите службу Azure AD B2C и выберите ее.
  4. Щелкните элемент Поставщики удостоверений, а затем выберите Новый поставщик OpenID Connect.
  5. Введите Имя. Например, введите Contoso.

Определите поставщик удостоверений OpenId Connect, добавив его в элемент ClaimsProviders в файле расширения вашей политики.

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

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

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

    <ClaimsProvider>
      <Domain>contoso.com</Domain>
      <DisplayName>Login with Contoso</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Contoso-OpenIdConnect">
          <DisplayName>Contoso</DisplayName>
          <Description>Login with your Contoso account</Description>
          <Protocol Name="OpenIdConnect"/>
          <Metadata>
            <Item Key="METADATA">https://your-identity-provider.com/.well-known/openid-configuration</Item>
            <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid profile</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
          </Metadata>
          <!-- <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_ContosoSecret"/>
          </CryptographicKeys> -->
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid"/>
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    

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

Каждый поставщик удостоверений OpenID Connect описывает документ метаданных, который содержит большую часть сведений, необходимых для выполнения входа. Документ метаданных включает такие сведения, как используемые URL-адреса и расположение открытых ключей подписывания службы. Документ метаданных OpenID Connect всегда находится в конечной точке, которая заканчивается на .well-known/openid-configuration. Для поставщика удостоверений OpenID Connect, которого требуется добавить, введите его URL-адрес метаданных.

В поле URL-адрес метаданных введите URL-адрес документа метаданных OpenID Connect.

В метаданные технического профиля <Item Key="METADATA"> введите URL-адрес документа метаданных OpenID Connect.

Идентификатор клиента и секрет

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

Секрет клиента не обязателен. Но вам нужно указать секрет клиента, если тип ответа — code, где используется секрет для обмена кода для маркера.

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

В метаданные технического профиля <Item Key="client_id"> введите идентификатор клиента.

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

Если требуется секрет клиента, сохраните секрет клиента, записанный ранее в арендаторе Azure AD B2C.

  1. Войдите на портал Azure.

  2. Убедитесь, что вы используете каталог, содержащий клиент Azure AD B2C. На панели инструментов портала выберите фильтр Каталог + подписка.

  3. В настройках портала на странице Каталоги и подписки найдите свой каталог Azure AD B2C в списке Имя каталога и выберите Переключить.

  4. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.

  5. На странице "Обзор" выберите Identity Experience Framework.

  6. Выберите Ключи политики, а затем щелкните Добавить.

  7. Для пункта Параметры выберите Manual.

  8. Введите имя ключа политики. Например, ContosoSecret. Префикс B2C_1A_ будет автоматически добавлен к имени ключа.

  9. В поле Секрет введите ранее записанный секрет клиента.

  10. Для параметра Использование ключа выберите Signature.

  11. Нажмите кнопку Создать.

  12. В XML-элемент CryptographicKeys добавьте следующий элемент:

    <CryptographicKeys>
      <Key Id="client_secret" StorageReferenceId="B2C_1A_ContosoSecret"/>
    </CryptographicKeys>
    

Область действия

Области определяют сведения и разрешения, которые требуется собрать от поставщика удостоверений, например openid profile. Чтобы получить маркер идентификатора от поставщика удостоверений, необходимо указать область openid.

Без маркера идентификатора пользователи не смогут войти в Azure AD B2C с помощью пользовательского поставщика удостоверений. Можно присоединить другие области (разделяемые пробелом). Сведения о том, какие другие области могут быть доступны, см. в документации пользовательского поставщика удостоверений.

В поле Область введите области из поставщика удостоверений. Например, openid profile.

В метаданные технического профиля <Item Key="scope"> введите области из поставщика удостоверений. Например, openid profile.

Тип ответа

Тип ответа описывает, какие сведения будут отправляться обратно в исходный вызов authorization_endpoint пользовательского поставщика удостоверений. Можно использовать следующие типы ответов:

  • code: в соответствии с потоком кода авторизации, код будет возвращаться обратно в Azure AD B2C. Azure AD B2C затем перейдет к вызову token_endpoint для обмена кода для маркера.
  • id_token: маркер идентификатора возвращается обратно в Azure AD B2C от пользовательского поставщика удостоверений.

В поле Тип ответа выберите code или id_token с учетом параметров поставщика удостоверений.

В метаданных технического профиля <Item Key="response_types"> выберите code или id_token с учетом параметров поставщика удостоверений.

Режим ответа

Режим ответа позволяет определить метод, который следует использовать для отправки данных обратно от пользовательского поставщика удостоверений в Azure AD B2C. Можно использовать следующие режимы ответов:

  • form_post: этот режим ответа рекомендуется использовать для максимальной безопасности. Ответ передается через HTTP-метод POST с кодом или маркером, закодированным в тексте с использованием формата application/x-www-form-urlencoded.
  • query: код или маркер возвращается в виде параметра запроса.

В поле Режим ответа выберите form_post или query с учетом параметров поставщика удостоверений.

В метаданных технического профиля <Item Key="response_mode"> выберите form_post или query с учетом параметров поставщика удостоверений.

Указание домена

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

Чтобы разрешить такое поведение, введите значение для указания домена. Чтобы перейти к пользовательскому поставщику удостоверений, добавьте параметр domain_hint=<domain hint value> в конец запроса при вызове Azure AD B2C для входа.

В поле Указание домена введите доменное имя, используемое в указании домена.

В XML-элемент технического профиля <Domain>contoso.com</Domain> введите доменное имя, используемое в указании домена. Например, contoso.com.

Сопоставление утверждений

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

  • Идентификатор пользователя: введите утверждение, которое предоставляет уникальный идентификатор для пользователя, выполнившего вход.
  • Отображаемое имя: введите утверждение, которое предоставляет отображаемое имя или полное имя пользователя.
  • Имя: введите утверждение, которое предоставляет имя пользователя.
  • Фамилия: введите утверждение, которое предоставляет фамилию пользователя.
  • Электронная почта: введите утверждение, которое предоставляет адрес электронной почты пользователя.

Элемент OutputClaims содержит список утверждений, возвращаемых поставщиком удостоверений. Сопоставьте имя утверждения, определенное в вашей политике, с именем, определенным в поставщике удостоверений. В элементе <OutputClaims> настройте атрибут PartnerClaimType, используя соответствующее имя утверждения, как определено вашим поставщиком удостоверений.

ClaimTypeReferenceId PartnerClaimType
issuerUserId Введите утверждение, которое предоставляет уникальный идентификатор для пользователя, выполнившего вход.
displayName Введите утверждение, которое предоставляет пользователю отображаемое имя или полное имя.
givenName Введите утверждение, которое предоставляет имя пользователя.
surName Введите утверждение, которое предоставляет фамилию пользователя.
email Введите утверждение, которое предоставляет адрес электронной почты пользователя.
identityProvider Введите утверждение, которое предоставляет имя издателя маркера. Например, iss. Если поставщик удостоверений не включает утверждение издателя в маркер, укажите для атрибута DefaultValue уникальный идентификатор поставщика удостоверений. Например, DefaultValue="contoso.com".

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

  1. В клиенте Azure AD B2C выберите Потоки пользователей.
  2. Выберите поток пользователя, для которого требуется добавить поставщика удостоверений.
  3. В разделе Поставщики удостоверений в социальных сетях выберите добавленного поставщика удостоверений (например, Contoso).
  4. Выберите Сохранить.

Тестирование потока пользователя

  1. Чтобы проверить политику, выберите Выполнить поток пользователя.
  2. В разделе Приложение выберите зарегистрированное ранее веб-приложение с именем testapp1. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
  3. Нажмите кнопку Выполнить поток пользователя.
  4. На странице регистрации или входа выберите поставщика удостоверений, с помощью которого хотите войти (например, Contoso).

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

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

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

  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-OpenIdConnect" />
  </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.
  1. Выберите политику проверяющей стороны, например B2C_1A_signup_signin.
  2. В разделе Приложение выберите зарегистрированное ранее веб-приложение. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
  3. Нажмите кнопку Выполнить.
  4. На странице регистрации или входа выберите Contoso для входа с помощью учетной записи Google.

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

Известные проблемы

  • Azure AD B2C не поддерживает JWE (веб-шифрование JSON) для обмена зашифрованными токенами с поставщиками удостоверений OpenID connect.

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

Дополнительные сведения см. в справочном руководстве Технический профиль OpenId Connect.