B2C/IEF Zurücksetzen des Kennworts mit Benutzername

Question

Ich erstelle eine benutzerdefinierte B2C-Richtlinie und versuche, die Kennwortzurücksetzung für lokale Konten, die mit einem Benutzernamen erstellt wurden, zu replizieren.

Ich kann den Benutzernamen von AD lesen, aber ich bin mir nicht sicher, wie die verifizierte E-Mail-Adresse für das Konto überprüft werden soll.

Derzeit, wenn der Benutzername korrekt ist, kann jede E-Mail-Adresse zur Überprüfung verwendet werden.

Technisches Profil:

<TechnicalProfile Id="SA-LocalAccountDiscoveryUsingLogonName"> 
     <DisplayName>Reset password using logon name</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.localaccountpasswordreset</Item> 
     </Metadata> 
     <IncludeInSso>false</IncludeInSso> 
     <OutputClaims> 
     <OutputClaim ClaimTypeReferenceId="signInName" Required="true" /> 
     <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" /> 
     <OutputClaim ClaimTypeReferenceId="objectId" /> 
     <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> 
     </OutputClaims> 
     <ValidationTechnicalProfiles> 
     <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingLogonName" /> 
     </ValidationTechnicalProfiles> 
    </TechnicalProfile> 

Validation Technisches Profil:

<TechnicalProfile Id="AAD-UserReadUsingLogonName"> 
     <Metadata> 
     <Item Key="Operation">Read</Item> 
     <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item> 
     </Metadata> 
     <InputClaims> 
     <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="signInNames.userName" Required="true" /> 
     </InputClaims> 
     <OutputClaims> 
     <OutputClaim ClaimTypeReferenceId="objectId" /> 
     <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> 
     </OutputClaims> 
     <IncludeTechnicalProfile ReferenceId="AAD-Common" /> 
     <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" /> 
    </TechnicalProfile> 

Benutzer Journey:

<UserJourney Id="PasswordReset"> 
    <OrchestrationSteps> 
    <!--Get user by username--> 
    <OrchestrationStep Order="1" Type="ClaimsExchange"> 
     <ClaimsExchanges> 
     <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="SA-LocalAccountDiscoveryUsingLogonName" /> 
     </ClaimsExchanges> 
    </OrchestrationStep> 

    <!--Reset password--> 
    <OrchestrationStep Order="2" Type="ClaimsExchange"> 
     <ClaimsExchanges> 
     <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="SA-LocalAccountPasswordReset" /> 
     </ClaimsExchanges> 
    </OrchestrationStep> 

    <!--Read remaining attributes of user--> 
    <OrchestrationStep Order="3" Type="ClaimsExchange"> 
     <ClaimsExchanges> 
     <ClaimsExchange Id="ReadUser" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" /> 
     </ClaimsExchanges> 
    </OrchestrationStep> 

    <!--Create token--> 
    <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> 
    </OrchestrationSteps> 
    <ClientDefinition ReferenceId="DefaultWeb" /> 
</UserJourney> 

Answer 1

Wenn Sie die E-Mail-Adresse sowohl für die "otherMails" und „strongAuthenticationEmailAddress schreiben "Eigenschaften während der Anmeldungsrichtlinie, dann können Sie überprüfen, ob die E-Mail-Adresse zugeordnet ist Der Benutzername wird während der Kennwortzurücksetzungsrichtlinie mithilfe einer REST-API angegeben.

muss Diese REST-API als Anspruchsanbieter deklariert werden:

<ClaimsProvider> 
    <DisplayName>REST APIs</DisplayName> 
    <TechnicalProfiles> 
     <TechnicalProfile Id="RestApi-CheckUser"> 
      <DisplayName>Check User REST API</DisplayName> 
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> 
      <Metadata> 
       <Item Key="ServiceUrl">Insert the REST API endpoint URL</Item> 
       <Item Key="AuthenticationType">None</Item> 
       <Item Key="SendClaimsIn">Body</Item> 
      </Metadata> 
      <InputClaims> 
       <InputClaim ClaimTypeReferenceId="signInName" /> 
       <InputClaim ClaimTypeReferenceId="email" /> 
      </InputClaims> 
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" /> 
     </TechnicalProfile> 
    </TechnicalProfiles> 
</ClaimsProvider> 

Die REST-API das Benutzerobjekt durch die "signInNames" und "otherMails" Eigenschaften mit Hilfe der Azure AD Graph API abfragen können (Sie können‘ t Lesen Sie die Eigenschaft "strongAuthenticationEmailAddress" mit dieser Graph-API und geben Sie, wie unter the REST API walkthrough beschrieben, 200 OK zurück, wenn die E-Mail-Adresse dem Benutzernamen oder 409 Conflict zugeordnet ist, falls dies nicht der Fall ist.

Das REST-API technische Profil kann dann als Validierungs technisches Profil aus dem „SA-LocalAccountDiscoveryUsingLogonName“ technischen Profil aufgerufen werden:

<TechnicalProfile Id="SA-LocalAccountDiscoveryUsingLogonName"> 
    <ValidationTechnicalProfiles> 
     <ValidationTechnicalProfile ReferenceId="RestApi-CheckUser" /> 
     <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingLogonName" /> 
    </ValidationTechnicalProfiles> 
</TechnicalProfile> 

Wenn das „RestApi-Checkuser“ technische Profil gibt 200 OK, dann ist die " Das technische Profil "AAD-UserReadUsingLogonName" wird aufgerufen und der Endbenutzer kann mit dem Zurücksetzen des Kennworts fortfahren. Wenn das technische Profil "RestApi-CheckUser" 409 Conflict zurückgibt, wird das technische Profil "AAD-UserReadUsingLogonName" nicht aufgerufen und der Endbenutzer kann nicht fortfahren.