Запретить пользователям Azure B2C входить в систему с адресом электронной почты, когда включен поток входа с именем пользователя.

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

Вот мои первые два UserJourney шага:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
  </ClaimsProviderSelections>
  <ClaimsExchanges>
    <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Username" />
  </ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="SignUpWithLogonUsernameExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonName" />
  </ClaimsExchanges>
</OrchestrationStep>

Технический профиль для SelfAsserted-LocalAccountSignin-Username.

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Username">
  <DisplayName>Local Account Signin</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="SignUpTarget">SignUpWithLogonUsernameExchange</Item>
    <Item Key="setting.operatingMode">Username</Item>
    <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
  </Metadata>
  <IncludeInSso>false</IncludeInSso>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="signInName" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
    <OutputClaim ClaimTypeReferenceId="password" Required="true" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

Метаданные SignUpTarget ссылаются на SignUpWithLogonUsernameExchange, который имеет технический профиль LocalAccountSignUpWithLogonName, как показано на втором этапе UserJourney.

<TechnicalProfile Id="LocalAccountSignUpWithLogonName">
  <DisplayName>Username signup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
    <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
    <Item Key="LocalAccountType">Username</Item>
    <Item Key="LocalAccountProfile">true</Item>
    <Item Key="language.button_continue">Create</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
  </CryptographicKeys>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="signInName" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" />
    <OutputClaim ClaimTypeReferenceId="newUser" />
    <!-- Optional claims, to be collected from the user -->
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surName" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonName" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

И технический профиль AAD-UserWriteUsingLogonName проверки.

<TechnicalProfile Id="AAD-UserWriteUsingLogonName">
  <Metadata>
    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
  </Metadata>
  <IncludeInSso>false</IncludeInSso>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.userName" Required="true" />
  </InputClaims>
  <PersistedClaims>
    <!-- Required claims -->
    <PersistedClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.userName" />
    <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="strongAuthenticationEmailAddress" />
    <PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password" />
    <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
    <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration" />
    <!-- Optional claims. -->
    <PersistedClaim ClaimTypeReferenceId="givenName" />
    <PersistedClaim ClaimTypeReferenceId="surname" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
    <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
  </OutputClaims>
  <IncludeTechnicalProfile ReferenceId="AAD-Common" />
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

Вот идентификаторы каждого пользователя:

Пользователь 1

"identities":[
  {
     "signInType":"emailAddress",
     "issuer":"{tenant}.onmicrosoft.com",
     "issuerAssignedId":"[email protected]"
  },
  {
     "signInType":"userPrincipalName",
     "issuer":"{tenant}.onmicrosoft.com",
     "issuerAssignedId":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX@{tenant}.onmicrosoft.com"
  }
]

Пользователь 2:

"identities":[
  {
     "signInType":"userName",
     "issuer":"{tenant}.onmicrosoft.com",
     "issuerAssignedId":"userTwo"
  },
  {
     "signInType":"userPrincipalName",
     "issuer":"{tenant}.onmicrosoft.com",
     "issuerAssignedId":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX@{tenant}.onmicrosoft.com"
  }
]

Любая помощь приветствуется.


person Ikeem Wilson    schedule 02.04.2021    source источник


Ответы (1)


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

Решение:

<TechnicalProfile Id="AAD-ReadUsingUsername">
   <Metadata>
      <Item Key="Operation">Read</Item>
      <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
   </Metadata>
   <InputClaims>
      <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.userName" Required="true" />
   </InputClaims>
   <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="objectId" />
   </OutputClaims>
</TechnicalProfile>
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Username">
...snip...
<ValidationTechnicalProfiles>
   <ValidationTechnicalProfile ReferenceId="AAD-ReadUsingUsername" />
   <ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
</ValidationTechnicalProfiles>
...snip...

Ссылки:
Ознакомьтесь с начальным пакетом
Технический профиль Azure AD R / W < / а>

person Jas Suri - MSFT    schedule 02.04.2021
comment
Я не знаю, как это сделать. Я понимаю, как создать технический профиль валидации, но не понимаю, как выдать ошибку с помощью ключей метаданных. И у меня есть signInNames.username в качестве входного утверждения в моем AAD-UserWriteUsingLogonName, но я не уверен, выполняет ли это чтение учетной записи, используя то, что вы просите signInNames.username. Я немного новичок в этом. - person Ikeem Wilson; 03.04.2021
comment
Добавлено полное решение. Ваша проблема не связана с AAD-UserWriteUsingLogonName, кроме того, что он объясняет, где вы пишете идентификатор имени пользователя при регистрации (signInNames.username). Технический профиль входа по умолчанию соответствует всем signInNames. Вставьте операцию чтения до входа в систему без взаимодействия, что является более явным путем явного чтения пользователя signInNames.username. - person Jas Suri - MSFT; 03.04.2021
comment
Ах! Я вижу сейчас. Полезно знать, что вы можете настроить Read, а затем использовать клавишу повышения ошибки, чтобы выдать ошибку, если входные утверждения не существуют. Спасибо за помощь. - person Ikeem Wilson; 03.04.2021