Настройка регистрации и входа с учетной записью LinkedIn - Azure AD B2C

Статья
06/01/2023

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

Примечание.

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

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

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

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

Создание приложения LinkedIn

Чтобы включить вход для пользователей с учетной записью LinkedIn в Azure Active Directory B2C (Azure AD B2C), необходимо создать приложение на веб-сайте разработчиков LinkedIn. Дополнительные сведения см. в разделе Поток кода авторизации. Если у вас нет учетной записи LinkedIn, вы можете создать ее, пройдя по ссылке https://www.linkedin.com/.

Выполните вход на сайт разработчиков LinkedIn с учетными данными для учетной записи LinkedIn.
Выберите My Apps (Мои приложения) и щелкните Create App (Создать приложение).
Введите имя приложения, страницу LinkedIn, URL-адрес политики конфиденциальности и добавьте логотип приложения.
Примите условия использования LinkedIn API и нажмите кнопку Create app (Создать приложение).
Перейдите на вкладку Auth (Проверка подлинности). В разделе Authentication Keys (Ключи проверки подлинности) скопируйте значения для параметров Client ID (Идентификатор клиента) и Client Secret (Секрет клиента). Оба значения необходимы для настройки LinkedIn в качестве поставщика удостоверений для вашего клиента. Секрет клиента — это важные учетные данные безопасности.
Щелкните значок карандаша рядом с заголовком Authorized redirect URLs for your app (Авторизованные URL-адреса перенаправления для приложения) и выберите Add redirect URL (Добавить URL-адрес перенаправления). Введите https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp. Если используется личный домен, введите https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp. Замените your-tenant-name именем своего арендатора, а вместо your-domain-name укажите имя вашего личного домена. При вводе имени вашего клиента необходимо использовать только строчные буквы, даже если в Azure AD B2C имя клиента определено с прописными буквами. Выберите Обновить.
По умолчанию приложение LinkedIn не утверждено для областей, связанных с входом. Чтобы запросить проверку, перейдите на вкладку Продукты и выберите Вход с помощью LinkedIn. После завершения проверки необходимые области будут добавлены в приложение.

Примечание.

Вы можете просмотреть области, которые в настоящее время разрешены для приложения, на вкладке Проверка подлинности в разделе Области OAuth 2.0.

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

Войдите на портал Azure с правами глобального администратора клиента Azure AD B2C.
Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
Выберите Все службы в левом верхнем углу окна портала Azure, найдите службу Azure AD B2C и выберите ее.
Щелкните элемент Поставщики удостоверений и выберите вариант LinkedIn.
Введите Имя. Например, LinkedIn.
В поле Идентификатор клиента введите идентификатор клиента созданного ранее приложения LinkedIn.
В качестве секрета клиента введите секрет клиента, записанный ранее.
Выберите Сохранить.

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

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

В клиенте Azure AD B2C выберите Потоки пользователей.
Выберите поток пользователя, для которого требуется добавить поставщик удостоверений LinkedIn.
В разделе Поставщики удостоверений социальных сетей выберите LinkedIn.
Выберите Сохранить.
Чтобы проверить политику, выберите Выполнить поток пользователя.
В разделе Приложение выберите зарегистрированное ранее веб-приложение с именем testapp1. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
Нажмите кнопку Выполнить поток пользователя.
На странице регистрации или входа выберите LinkedIn, чтобы выполнить вход с использованием учетной записи LinkedIn.

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

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

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

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

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

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

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

Откройте файл SocialAndLocalAccounts/TrustFrameworkExtensions.xml в редакторе. Этот файл находится в начальном пакете пользовательской политики, скачанном в составе одного из необходимых компонентов.
Найдите элемент ClaimsProviders. Если он не существует, добавьте его в корневой элемент.

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

<ClaimsProvider>
  <Domain>linkedin.com</Domain>
  <DisplayName>LinkedIn</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LinkedIn-OAuth2">
      <DisplayName>LinkedIn</DisplayName>
      <Protocol Name="OAuth2" />
      <Metadata>
        <Item Key="ProviderName">linkedin</Item>
        <Item Key="authorization_endpoint">https://www.linkedin.com/oauth/v2/authorization</Item>
        <Item Key="AccessTokenEndpoint">https://www.linkedin.com/oauth/v2/accessToken</Item>
        <Item Key="ClaimsEndpoint">https://api.linkedin.com/v2/me</Item>
        <Item Key="scope">r_emailaddress r_liteprofile</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="external_user_identity_claim_id">id</Item>
        <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
        <Item Key="ResolveJsonPathsInJsonTokens">true</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="client_id">Your LinkedIn application client ID</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="client_secret" StorageReferenceId="B2C_1A_LinkedInSecret" />
      </CryptographicKeys>
      <InputClaims />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName.localized" />
        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName.localized" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="linkedin.com" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="ExtractGivenNameFromLinkedInResponse" />
        <OutputClaimsTransformation ReferenceId="ExtractSurNameFromLinkedInResponse" />
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Замените значение client_id на идентификатор клиента приложения LinkedIn, записанный ранее.
Сохраните файл.

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

В техническом профиле LinkedIn необходимо добавить преобразования утверждений ExtractGivenNameFromLinkedInResponse и ExtractSurNameFromLinkedInResponse в список ClaimsTransformations. Если в файле не определен элемент ClaimsTransformations, добавьте родительские XML-элементы, как показано ниже. Для преобразований утверждений также требуется определить новый тип утверждения с именем nullStringClaim.

Добавьте элемент BuildingBlocks в начало файла TrustFrameworkExtensions.xml. См. TrustFrameworkBase.xml в качестве примера.

<BuildingBlocks>
  <ClaimsSchema>
    <!-- Claim type needed for LinkedIn claims transformations -->
    <ClaimType Id="nullStringClaim">
      <DisplayName>nullClaim</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>A policy claim to store output values from ClaimsTransformations that aren't useful. This claim should not be used in TechnicalProfiles.</AdminHelpText>
      <UserHelpText>A policy claim to store output values from ClaimsTransformations that aren't useful. This claim should not be used in TechnicalProfiles.</UserHelpText>
    </ClaimType>
  </ClaimsSchema>

  <ClaimsTransformations>
    <!-- Claim transformations needed for LinkedIn technical profile -->
    <ClaimsTransformation Id="ExtractGivenNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
    <ClaimsTransformation Id="ExtractSurNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="surname" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="surname" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
  </ClaimsTransformations>
</BuildingBlocks>

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

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

Откройте файл 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="LinkedInExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="LinkedInExchange" TechnicalProfileReferenceId="LinkedIn-OAuth2" />
  </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.

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

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

Миграция с версии 1.0 на версию 2.0

Компания LinkedIn недавно обновила API-интерфейсы с версии 1.0 до версии 2.0. Чтобы перенести существующую конфигурацию в новую конфигурацию, используйте сведения в следующих разделах для обновления элементов в техническом профиле.

Замена элементов в метаданных

В существующем элементе Metadata в техническом профиле измените следующие составляющие элемента с:

<Item Key="ClaimsEndpoint">https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address,headline)</Item>
<Item Key="scope">r_emailaddress r_basicprofile</Item>

Кому:

<Item Key="ClaimsEndpoint">https://api.linkedin.com/v2/me</Item>
<Item Key="scope">r_emailaddress r_liteprofile</Item>

Добавление элементов в метаданные

В существующем разделе Metadata в техническом профиле обновите следующие составляющие элемента:

<Item Key="external_user_identity_claim_id">id</Item>
<Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
<Item Key="ResolveJsonPathsInJsonTokens">true</Item>

Обновление OutputClaims

В существующем разделе OutputClaims в техническом профиле измените следующие элементы OutputClaim с:

<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName" />

Кому:

<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName.localized" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName.localized" />

Добавление новых элементов OutputClaimsTransformation

В разделе OutputClaimsTransformation в техническом профиле добавьте следующие элементы OutputClaimsTransformation:

<OutputClaimsTransformation ReferenceId="ExtractGivenNameFromLinkedInResponse" />
<OutputClaimsTransformation ReferenceId="ExtractSurNameFromLinkedInResponse" />

Определение новых преобразований утверждений и типов утверждения

В последнем шаге вы добавили новые преобразования утверждений, которые необходимо определить. Чтобы определить преобразования утверждений, добавьте их в список ClaimsTransformations. Если в файле не определен элемент ClaimsTransformations, добавьте родительские XML-элементы, как показано ниже. Для преобразований утверждений также требуется определить новый тип утверждения с именем nullStringClaim.

Элемент BuildingBlocks следует указать в начале файла. См. TrustframeworkBase.xml в качестве примера.

<BuildingBlocks>
  <ClaimsSchema>
    <!-- Claim type needed for LinkedIn claims transformations -->
    <ClaimType Id="nullStringClaim">
      <DisplayName>nullClaim</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>A policy claim to store unuseful output values from ClaimsTransformations. This claim should not be used in a TechnicalProfiles.</AdminHelpText>
      <UserHelpText>A policy claim to store unuseful output values from ClaimsTransformations. This claim should not be used in a TechnicalProfiles.</UserHelpText>
    </ClaimType>
  </ClaimsSchema>

  <ClaimsTransformations>
    <!-- Claim transformations needed for LinkedIn technical profile -->
    <ClaimsTransformation Id="ExtractGivenNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
    <ClaimsTransformation Id="ExtractSurNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="surname" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="surname" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
  </ClaimsTransformations>
</BuildingBlocks>

Получение адреса электронной почты

В рамках миграции LinkedIn с версии 1.0 на версию 2.0 для получения адреса электронной почты требуется совершить дополнительный вызов другого API. Чтобы получить адрес электронной почты во время регистрации, выполните следующие действия.

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

Добавьте следующий поставщик утверждений, который выполняет запрос к API LinkedIn /emailAddress. Чтобы авторизовать этот запрос, необходим маркер доступа LinkedIn.

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="API-LinkedInEmail">
      <DisplayName>Get LinkedIn email</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
          <Item Key="ServiceUrl">https://api.linkedin.com/v2/emailAddress?q=members&amp;projection=(elements*(handle~))</Item>
          <Item Key="AuthenticationType">Bearer</Item>
          <Item Key="UseClaimAsBearerToken">identityProviderAccessToken</Item>
          <Item Key="SendClaimsIn">Url</Item>
          <Item Key="ResolveJsonPathsInJsonTokens">true</Item>
      </Metadata>
      <InputClaims>
          <InputClaim ClaimTypeReferenceId="identityProviderAccessToken" />
      </InputClaims>
      <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="elements[0].handle~.emailAddress" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Добавьте следующий шаг оркестрации в путь взаимодействия пользователя, чтобы при входе пользователя поставщик утверждений API активировался с помощью LinkedIn. Обязательно обновите номер Order соответствующим образом. Добавьте этот шаг сразу после шага оркестрации, запускающего технический профиль LinkedIn.

<!-- Extra step for LinkedIn to get the email -->
<OrchestrationStep Order="3" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
      <Value>identityProvider</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
      <Value>identityProvider</Value>
      <Value>linkedin.com</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="GetEmail" TechnicalProfileReferenceId="API-LinkedInEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

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

Полный пример политики, использующей поставщик удостоверений LinkedIn, см. в разделе Начальный пакет настраиваемой политики.

Миграция с версии 1.0 на версию 2.0

Компания LinkedIn недавно обновила API-интерфейсы с версии 1.0 до версии 2.0. В рамках этой миграции Azure AD B2C может получить полное имя пользователя LinkedIn только во время регистрации. Если адрес электронной почты является одним из атрибутов, сбор которых выполняется во время регистрации, пользователь должен вручную ввести адрес электронной почты и выполнить его проверку.

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

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

Создание приложения LinkedIn

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

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

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

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

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

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

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

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

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

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

Миграция с версии 1.0 на версию 2.0

Замена элементов в метаданных

Добавление элементов в метаданные

Обновление OutputClaims

Добавление новых элементов OutputClaimsTransformation

Определение новых преобразований утверждений и типов утверждения

Получение адреса электронной почты

Миграция с версии 1.0 на версию 2.0

Дополнительные ресурсы