UserJourneys

Статья
01/17/2024

Примечание.

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

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

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

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

<TrustFrameworkPolicy  ...>
  ...
  <UserJourneys>
    ...
  </UserJourneys>
</TrustFrameworkPolicy>

Элемент UserJourneys содержит следующий элемент:

Элемент	Вхождения	Description
UserJourney	1:n	Путь взаимодействия пользователя, определяющий все конструкции, необходимые для полного потока пользователя.

Элемент UserJourney содержит следующий атрибут.

Атрибут	Обязательное поле	Описание
Артикул	Да	Идентификатор пути взаимодействия пользователя, который можно использовать для ссылки на этот путь из других элементов в политике. Элемент DefaultUserJourneyполитики проверяющей стороны указывает на этот атрибут.
DefaultCpimIssuerTechnicalProfileReferenceId	No	Идентификатор ссылки на технический профиль издателя маркера по умолчанию. Например, издатель маркера JWT, издатель маркера SAML или пользовательская ошибка OAuth2. Если в пути взаимодействия пользователя или промежуточном пути уже есть другой шаг оркестрации `SendClaims`, присвойте атрибут `DefaultCpimIssuerTechnicalProfileReferenceId` техническому профилю издателя маркеров для пути взаимодействия пользователя.

Элемент UserJourney содержит следующие элементы.

Элемент	Вхождения	Description
AuthorizationTechnicalProfiles	00:14	Список технических профилей авторизации.
OrchestrationSteps	1:n	Последовательность оркестрации, которая должна соблюдаться для успешного выполнения транзакции. Каждый путь взаимодействия пользователя состоит из упорядоченного списка шагов оркестрации, которые должны выполняться в соответствующей последовательности. Если какой-либо шаг завершится ошибкой, выполнение транзакции завершается сбоем.

AuthorizationTechnicalProfiles

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

Элемент AuthorizationTechnicalProfiles содержит следующий элемент:

Элемент	Вхождения	Description
AuthorizationTechnicalProfile	00:14	Ссылка на технический профиль, используемая для авторизации пользователя.

Элемент AuthorizationTechnicalProfile содержит следующий атрибут:

Атрибут	Обязательное поле	Описание
ReferenceId	Да	Идентификатор технического профиля, который необходимо выполнить.

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

<UserJourney Id="UserInfoJourney" DefaultCpimIssuerTechnicalProfileReferenceId="UserInfoIssuer">
  <Authorization>
    <AuthorizationTechnicalProfiles>
      <AuthorizationTechnicalProfile ReferenceId="UserInfoAuthorization" />
    </AuthorizationTechnicalProfiles>
  </Authorization>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
     ...

OrchestrationSteps

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

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

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

<UserJourney Id="SignUpOrSignIn">
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      ...

Элемент OrchestrationSteps содержит следующий элемент:

Элемент	Вхождения	Description
OrchestrationStep	1:n	Упорядоченный шаг оркестрации.

Элемент OrchestrationStep содержит следующие атрибуты.

Атрибут	Обязательное поле	Описание:
`Order`	Да	Порядок шагов оркестрации. Значение атрибута `Order` начинается с `1` `N`. Таким образом, если у вас есть 10 шагов и вы удалили второй шаг, необходимо переначисить шаги 3–10, чтобы стать двумя до девяти.
`Type`	Да	Тип шага оркестрации. Возможные значения: ClaimsProviderSelection — указывает, что шаг оркестрации предоставляет пользователю различные варианты поставщиков утверждений, из которых нужно выбрать одного. CombinedSignInAndSignUp — указывает, что на шаге оркестрации отображается общая страница для входа поставщика социальных сетей и для регистрации локальной учетной записи. ClaimsExchange — указывает, что на шаге оркестрации выполняется обмен утверждениями с поставщиком утверждений. GetClaims — указывает, что на шаге оркестрации обрабатываются данные утверждений, отправленные в Azure AD B2C проверяющей стороной, с использованием конфигурации `InputClaims`. InvokeSubJourney — указывает, что на шаге оркестрации выполняется обмен утверждениями с вложенным путем. SendClaims — указывает, что на данном шаге оркестрации проверяющей стороне отправляется утверждение с маркером, выданным издателем утверждений.
ContentDefinitionReferenceId	No	Идентификатор определения содержимого, связанного с этим шагом оркестрации. Обычно идентификатор ссылки на определение содержимого определяется в техническом профиле с самостоятельным подтверждением. Однако иногда в Azure AD B2C требуется показать некоторые данные, не используя технический профиль. Есть два примера. При типе шага оркестрации `ClaimsProviderSelection` или `CombinedSignInAndSignUp` Azure AD B2C необходимо отобразить выбор поставщика удостоверений без технического профиля.
CpimIssuerTechnicalProfileReferenceId	No	Тип шага этапа оркестрации — `SendClaims`. Это свойство определяет идентификатор технического профиля поставщика утверждений, выдающего маркер для проверяющей стороны. Если это значение не указано, маркер проверяющей стороны не создается.

Элемент OrchestrationStep может содержать следующие элементы.

Элемент	Вхождения	Description
Предварительные условия	0:n	Список предварительных условий, которые необходимо соблюдать для выполнения шага оркестрации.
ClaimsProviderSelections	0:n	Список возможных поставщиков утверждений для шага оркестрации.
ClaimsExchanges	0:n	Список обмена утверждениями для шага оркестрации.
JourneyList	00:14	Список возможных вложенных путей для шага оркестрации.

Предварительные условия

Шаги оркестрации можно выполнить условно на основе предварительных условий, определенных на этапе оркестрации. Элемент Preconditions содержит список предварительных условий, которые будут оцениваться. При соблюдении предварительного условия выполняется переход от соответствующего шага оркестрации к следующему.

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

Элемент Preconditions содержит следующий элемент:

Элемент	Вхождения	Description
Precondition	1:n	Предварительное условие, которое нужно оценить.

Precondition

Элемент Precondition содержит следующие атрибуты.

Атрибут	Обязательное поле	Описание:
`Type`	Да	Тип выполняемой проверки или запроса для данного предварительного условия. Для этого элемента можно установить значение ClaimsExist, которое указывает, что действия должны выполняться, если указанные утверждения существуют в текущем наборе утверждений пользователя, или значение ClaimEquals, указывающее на то, что действия следует выполнить, если указанное утверждение существует и его значение соответствует указанному.
`ExecuteActionsIf`	Да	Определяет, в каком случае предварительное условие считается выполненным. Возможные значения: `true` или `false`. Если задано значение `true`, предварительное условие считается выполненным, если утверждение ему соответствует. При значении `false` предварительное условие считается выполненным, если утверждение ему не соответствует.

Элементы Precondition содержат следующие элементы:

Элемент	Вхождения	Description
Значение	1:2	Идентификатор типа утверждения. Утверждение уже определено в разделе схемы утверждений в файле политики или файле родительской политики. Если предусловие имеет тип `ClaimEquals`, второй элемент `Value` содержит проверяемое значение.
Действие	1:1	Действие, которое нужно выполнить, если предварительное условие будет удовлетворено. Возможное значение: `SkipThisOrchestrationStep`. Выполняется переход от соответствующего шага оркестрации к следующему.

Каждое предварительное условие оценивает одно утверждение. Существует два типа предварительных условий:

ClaimsExist — указывает, что действия должны выполняться в том случае, если указанные утверждения есть в наборе утверждений текущего пользователя.
ClaimEquals — указывает, что действия должны выполняться в том случае, если указанное утверждение существует и его значение равно указанному. При проверке выполняется порядковое сравнение с учетом регистра. При проверке утверждения логического типа используйте True или False.

Если утверждение имеет значение NULL или не инициализировано, то предварительное условие игнорируется, независимо от значения ExecuteActionsIf: true или false. Рекомендуется проверять оба условия: и наличие утверждения, и его равенство значению.

Примером сценария может быть запрос защиты MFA для пользователя, если он задал для MfaPreference значение Phone. Чтобы реализовать эту условную логику, проверьте, существует ли утверждение MfaPreference, а также убедитесь, что значение утверждения равно Phone. В следующем коде XML показано, как реализовать эту логику с предварительными условиями.

<Preconditions>
  <!-- Skip this orchestration step if MfaPreference doesn't exist. -->
  <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
    <Value>MfaPreference</Value>
    <Action>SkipThisOrchestrationStep</Action>
  </Precondition>
  <!-- Skip this orchestration step if MfaPreference doesn't equal to Phone. -->
  <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
    <Value>MfaPreference</Value>
    <Value>Phone</Value>
    <Action>SkipThisOrchestrationStep</Action>
  </Precondition>
</Preconditions>

Примеры предварительных условий

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

<OrchestrationStep Order="2" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

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

<OrchestrationStep Order="3" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
      <Value>authenticationSource</Value>
      <Value>localAccountAuthentication</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
  </ClaimsExchanges>
</OrchestrationStep>

Элемент Preconditions позволяет проверить несколько предварительных условий. В следующем примере проверяется, существуют ли элементы objectId или email. Если первое условие имеет значение true, путь взаимодействия пользователя переходит к следующему шагу оркестрации.

<OrchestrationStep Order="4" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>email</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="SelfAsserted-SocialEmail" TechnicalProfileReferenceId="SelfAsserted-SocialEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

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

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

Кнопки. Начинается с типа ClaimsProviderSelection или CombinedSignInAndSignUp, который содержит список вариантов для выбора. От порядка вариантов в элементе ClaimsProviderSelections зависит порядок кнопок, представленных пользователю.
Действия. За ними следует тип ClaimsExchange. ClaimsExchange содержит список действий. Действие — это ссылка на технический профиль, например OAuth2, OpenID Connect, преобразование утверждений или самостоятельное подтверждение. Когда пользователь нажимает одну из кнопок, выполняется соответствующее действие.

Элемент ClaimsProviderSelections содержит следующий элемент:

Элемент	Вхождения	Description
ClaimsProviderSelection	1:n	Предоставляет список доступных для выбора поставщиков утверждений.

Элемент ClaimsProviderSelections содержит следующие атрибуты:

Атрибут	Обязательное поле	Описание
DisplayOption	No	Управляет поведением, если для выбора доступен только один вариант поставщика утверждений. Возможные значения. `DoNotShowSingleProvider` (по умолчанию) — пользователь сразу перенаправляется к федеративному поставщику удостоверений. `ShowSingleProvider` — Azure AD B2C представляет страницу входа с возможностью выбрать поставщик удостоверений. Чтобы использовать этот атрибут, версия определения содержимого должна быть `urn:com:microsoft:aad:b2c:elements:contract:providerselection:1.0.0` и выше.

Элемент ClaimsProviderSelection содержит следующие атрибуты.

Атрибут	Обязательное поле	Описание
TargetClaimsExchangeId	No	Идентификатор обмена утверждениями, выполняемого на следующем шаге оркестрации выбора поставщика утверждений. Можно задать только данный атрибут или атрибут ValidationClaimsExchangeId, но не оба.
ValidationClaimsExchangeId	No	Идентификатор обмена утверждениями, выполняемого на текущем шаге оркестрации для проверки выбора поставщика утверждений. Можно задать только данный атрибут или атрибут TargetClaimsExchangeId, но не оба.

Пример выбора поставщика утверждений

На следующем шаге оркестрации пользователь может войти с помощью Facebook, LinkedIn, X, Google или локальной учетной записи. Если пользователь выбирает один из поставщиков удостоверений социальных сетей, второй шаг оркестрации выполняется с выбранным обменом утверждениями, указанном в атрибуте TargetClaimsExchangeId. Второй шаг оркестрации перенаправляет пользователя к поставщику удостоверений социальных сетей для завершения процесса входа в систему. Если пользователь решит выполнить вход с использованием локальной учетной записи, Azure AD B2C остается на том же шаге оркестрации (той же странице регистрации или входа в систему) и пропускает второй этап оркестрации.

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="LinkedInExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="TwitterExchange" />
    <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
    <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
  </ClaimsProviderSelections>
  <ClaimsExchanges>
  <ClaimsExchange Id="LocalAccountSigninEmailExchange"
        TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
  </ClaimsExchanges>
</OrchestrationStep>


<OrchestrationStep Order="2" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
    <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
    <ClaimsExchange Id="LinkedInExchange" TechnicalProfileReferenceId="LinkedIn-OAUTH" />
    <ClaimsExchange Id="TwitterExchange" TechnicalProfileReferenceId="Twitter-OAUTH1" />
  </ClaimsExchanges>
</OrchestrationStep>

ClaimsExchanges

Элемент ClaimsExchanges содержит следующий элемент:

Элемент	Вхождения	Description
ClaimsExchange	1:n	В зависимости от используемого технического профиля, этот элемент перенаправляет клиента в соответствии с выбранным элементом ClaimsProviderSelection либо выполняет вызов сервера для обмена утверждениями.

Элемент ClaimsExchange содержит следующие атрибуты.

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

JourneyList

Элемент JourneyList содержит следующий элемент:

Элемент	Вхождения	Description
Кандидат	1:1	Ссылка на вложенный путь, который необходимо вызвать.

Кандидат

Элемент Candidate содержит следующие атрибуты:

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

Поделиться через