Почему единый вход не работает правильно для Azure AD B2 C пользовательских политик - PullRequest
Новая
       22

Почему единый вход не работает правильно для Azure AD B2 C пользовательских политик

1 голос
/ 15 января 2020

В настоящее время мы используем Azure B2 C для аутентификации с помощью приложения React. js. Используемая нами библиотека - это msal. js.

Изначально мы использовали стандартный поток пользователей с включенным SSO, а библиотека msal js работала правильно (и продолжает работать). В этом потоке приложений первый вызов B2 C будет запрашивать id_token, а затем инициировать второй вызов в iframe, который автоматически сработает, потому что пользователь уже вошел в систему. Все это произойдет автоматически, и пользователь просто увидеть себя вошедшим без проблем. В этом случае вызов для аутентификации в iframe возвращает 302 назад нашему приложению с access_token для доступа к нашему API.

Теперь мы перешли на пользовательскую политику для настройки страницы входа и использования * 1046. *. Это было настроено с использованием пользовательских политик и правильно работает с многофакторной аутентификацией для входа в систему. Поток работает следующим образом:

  • Первый вызов msal. js превращается в B2 C (/ authorize ) вызывает запрос id_token и корректно следует потоку для входа в систему.
  • Второй вызов B2 C (/ authorize) также выполняется в iframe, но вместо возврата 302, он возвращает значение 200, которое затем (правильно) не отображается, поскольку заголовок, отправленный из B2 C, включает параметры X-Frame-Options: заголовок deny
  • MSAL ждет 6 секунд для возврата iframe, и потому что это не так, то инициирует перенаправление на страницу входа для токена доступа, который работает, но требует от пользователя дважды войти в систему.

Все это происходит (я полагаю), потому что SSO неправильно работает с пользовательской политикой. В первом сценарии с потоком пользователей из B2 C SSO запускается и автоматически перенаправляет пользователя обратно в приложение с токеном доступа, во втором, поскольку SSO не работает, пользователь должен войти в систему дважды.

Моя настраиваемая политика выглядит следующим образом, построенная на примерах, приведенных в (очень редкой) документации для настраиваемых политик с B2 C:

  • Технический профиль существует и выглядит как следующее: 
<TechnicalProfile Id="SM-AAD">
  <DisplayName>Session Mananagement Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="objectId" />
    <PersistedClaim ClaimTypeReferenceId="signInName" />
    <PersistedClaim ClaimTypeReferenceId="authenticationSource" />
    <PersistedClaim ClaimTypeReferenceId="identityProvider" />
    <PersistedClaim ClaimTypeReferenceId="newUser" />
    <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
  </OutputClaims>
</TechnicalProfile>
  • Каждый из технических профилей, которые используются для чтения и записи информации в каталог, ссылаются на этот технический профиль, например. 
<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
  • В моем файле профиля (SignUpOfSignIn. xml) у меня есть следующее под 
<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" KeepAliveInDays="7" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  <ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
  • В моем UserJourney для этой пользовательской политики каждый шаг оркестровки относится к техническому профилю, который включает в себя технический профиль SM-AAD для управления сеансом, за исключением PhoneFactor (который использует собственный технический профиль SM-MFA, для которого isActiveMfaSession имеет значение true)

Несмотря на все это Я не могу настроить единый вход для правильной работы с пользовательским профилем. Одна вещь, которую я заметил, - то, что ClaimType "objectIdFromSession", который является частью профиля SSO, не используется. Я бы подумал, что это будет использовано для определения того, следует ли пропустить этап оркестровки, верно ли это?

Любая другая помощь или подсказки относительно того, что может быть неправильным, будет принята с благодарностью.

...