Правила паролей на основе истории или других пользовательских атрибутов

Question

Есть ли в AAD B2C какие-либо средства, позволяющие мне запретить пользователям использовать pwds, в которых есть их имена или которые ранее использовались одним и тем же пользователем?Могу ли я сделать первое с помощью политики IEF и функции REST?(Я подозреваю, что не предполагал, что ни на каком этапе мой код не будет иметь доступа к значению pwd, но, возможно, я ошибаюсь, а утверждение pwd - это просто еще одно утверждение)

Answer 1

Пользовательская политика может проверить новый пароль, если вы хотите реализовать для этого REST API.

Например, для сброса пароля можно добавить один технический профиль проверки, который вызываетAPI REST, чтобы проверить, является ли новый пароль действительным для текущего пользователя по истории паролей, и другой технический профиль проверки, который вызывает API REST, чтобы затем сохранить новый пароль для текущего пользователя в истории паролей:

<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
  <DisplayName>Change password (username)</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  ...
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="objectId" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="API-CheckNewPassword" />
    <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId" />
    <ValidationTechnicalProfile ReferenceId="API-SaveNewPassword" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

Лучше всего хешировать новый пароль перед его передачей в API REST (хотя это ограничит возможность определения API REST, содержит ли новый пароль имя пользователя) для безопасности.

Вы можете хешироватьновый пароль, использующий преобразование хэша утверждает :

<ClaimsTransformation Id="HashNewPassword" TransformationMethod="Hash">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="newPassword" TransformationClaimType="plaintext" />
    <InputClaim ClaimTypeReferenceId="objectId" TransformationClaimType="salt" />
  </InputClaims>
  <InputParameters>
    <InputParameter Id="randomizerSecret" DataType="string" Value="B2C_1A_MyRandomizerSecret" />
  </InputParameters>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="newPasswordHash" TransformationClaimType="hash" />
  </OutputClaims>
</ClaimsTransformation>

<ClaimsProvider>
  <DisplayName>APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="API-CheckNewPassword">
      <DisplayName>Check New Password API</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      ...
      <InputClaimTransformations>
        <InputClaimTransformation ReferenceId="HashNewPassword" />
      </InputClaimTransformations>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="objectId" />
        <InputClaim ClaimTypeReferenceId="newPasswordHash" />
      </InputClaims>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>