Condividi tramite

Configurare la modifica della password usando criteri personalizzati in Azure Active Directory B2C

  • Articolo

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

Prima di iniziare, utilizza il selettore Scegli un tipo di criterio nella parte superiore di questa pagina per scegliere il tipo di criterio che si sta configurando. Azure Active Directory B2C offre due metodi per definire il modo in cui gli utenti interagiscono con le applicazioni: tramite flussi utente predefiniti o tramite criteri personalizzati completamente configurabili. I passaggi necessari in questo articolo sono diversi per ogni metodo.

È possibile configurare Azure Active Directory B2C (Azure AD B2C) in modo che un utente che ha eseguito l'accesso con un account locale possa modificare la password senza usare la verifica tramite posta elettronica per dimostrare la propria identità.

Il flusso di modifica della password prevede i passaggi seguenti:

  1. L'utente accede al proprio account locale. Se la sessione è ancora attiva, Azure AD B2C autorizza l'utente e passa al passaggio successivo.

  2. In Vecchia password l'utente verifica la vecchia password. In Nuova password creano e confermano la nuova password.

    Screenshot che mostra due dialoghi numerati per apportare una modifica della password.

Suggerimento

Un utente può usare il flusso di modifica della password descritto in questo articolo solo quando conosce la password e vuole modificare la password. È consigliabile abilitare anche la reimpostazione della password self-service per supportare i casi in cui l'utente dimentica la password.

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

Prerequisiti

Aggiungere gli elementi

  1. Aprire il file TrustFrameworkExtensions.xml . Aggiungere l'elemento ClaimType seguente all'elemento ClaimsSchema con un identificatore di oldPassword:

    <BuildingBlocks>
  <ClaimsSchema>
    <ClaimType Id="oldPassword">
      <DisplayName>Old Password</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your old password</UserHelpText>
      <UserInputType>Password</UserInputType>
    </ClaimType>
  </ClaimsSchema>
</BuildingBlocks>

  2. Un elemento ClaimsProvider contiene il profilo tecnico che autentica l'utente. Aggiungere i seguenti provider di attestazioni all'elemento ClaimsProviders :

    <ClaimsProviders>
  <ClaimsProvider>
    <DisplayName>Local Account SignIn</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="login-NonInteractive-PasswordChange">
        <DisplayName>Local Account SignIn</DisplayName>
        <InputClaims>
          <InputClaim ClaimTypeReferenceId="oldPassword" PartnerClaimType="password" Required="true" />
          </InputClaims>
        <IncludeTechnicalProfile ReferenceId="login-NonInteractive" />
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
  <ClaimsProvider>
    <DisplayName>Local Account Password Change</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="LocalAccountWritePasswordChangeUsingObjectId">
        <DisplayName>Change password (username)</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
          <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
        </Metadata>
        <InputClaims>
          <InputClaim ClaimTypeReferenceId="objectId" />
        </InputClaims>
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="oldPassword" Required="true" />
          <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
          <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
        </OutputClaims>
        <ValidationTechnicalProfiles>
          <ValidationTechnicalProfile ReferenceId="login-NonInteractive-PasswordChange" />
          <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId" />
        </ValidationTechnicalProfiles>
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
</ClaimsProviders>

  3. L'elemento UserJourneys definisce il percorso che l'utente accetta quando interagisce con l'applicazione. Aggiungere l'elemento UserJourneys , se non esiste, con l'identificatore UserJourney di PasswordChange:

    <UserJourneys>
  <UserJourney Id="PasswordChange">
    <OrchestrationSteps>
      <OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="LocalAccountSigninEmailExchange" />
        </ClaimsProviderSelections>
      </OrchestrationStep>
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="3" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordChangeUsingObjectId" />
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="4" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
    <ClientDefinition ReferenceId="DefaultWeb" />
  </UserJourney>
</UserJourneys>

  4. Salvare il file dei criteriTrustFrameworkExtensions.xml .

  5. Copiare il file ProfileEdit.xml scaricato con il pacchetto starter e denominarlo ProfileEditPasswordChange.xml.

  6. Aprire il nuovo file e aggiornare l'attributo PolicyId con un valore univoco. Questo valore è il nome della politica. Ad esempio, B2C_1A_profile_edit_password_change.

  7. Modificare l'attributo ReferenceId in DefaultUserJourney in modo che corrisponda all'ID del nuovo percorso utente creato. Ad esempio, PasswordChange.

  8. Salvare le modifiche.

Caricare e testare la normativa

  1. Accedi al portale di Azure.
  2. Se si dispone dell'accesso a più tenant, selezionare l'icona Impostazioni nel menu superiore per passare al tenant di Azure AD B2C dal menu Directory + sottoscrizioni.
  3. Scegliere Tutti i servizi nell'angolo in alto a sinistra del portale di Azure e quindi cercare e selezionare Azure AD B2C.
  4. Selezionare Identity Experience Framework.
  5. In Criteri personalizzati selezionare Carica criterio.
  6. Selezionare Sovrascrivi la politica se esistente e quindi cercare e selezionare il file TrustFrameworkExtensions.xml.
  7. Selezionare Carica.
  8. Ripetere i passaggi da 5 a 7 per il file della relying party, ad esempio ProfileEditPasswordChange.xml.

Esegui la politica

  1. Apri la politica che hai modificato. Ad esempio, B2C_1A_profile_edit_password_change.
  2. In Applicazione selezionare l'applicazione registrata in precedenza. Per visualizzare il token, l'URL di risposta dovrebbe visualizzare https://jwt.ms.
  3. Selezionare Esegui adesso. Nella nuova scheda visualizzata rimuovere "&prompt=login" dall'URL e aggiornare la scheda. Accedere quindi con l'account creato in precedenza. Una finestra di dialogo di modifica della password consente di modificare la password.

Contenuti correlati