Azure Active Directory B2C: modificare l'iscrizione per aggiungere nuove attestazioni e configurare l'input utente.

Nota

I criteri personalizzati sono disponibili in anteprima pubblica.

I criteri personalizzati sono stati progettati principalmente per professionisti della gestione delle identità che devono affrontare scenari complessi. Per la maggior parte degli scenari è consigliabile usare i criteri predefiniti di Azure Active Directory B2C. I criteri predefiniti sono più facili da impostare per la configurazione. È possibile usare i criteri predefiniti e i criteri personalizzati nello stesso tenant di Azure Active Directory B2C. Per altre informazioni, vedere la panoramica dei criteri personalizzati.

Questo articolo illustra come aggiungere una nuova voce specificata dall'utente, un'attestazione, al percorso utente di iscrizione. La voce verrà configurata come elenco a discesa e verrà indicato se è obbligatoria.

Prerequisiti

  • Completare la procedura descritta nell'articolo Introduzione ai criteri personalizzati. Prima di procedere, testare il percorso utente di iscrizione/accesso per l'iscrizione di un nuovo account locale.

La raccolta dei dati iniziali dagli utenti avviene mediante l'iscrizione/accesso. In un secondo momento è possibile raccogliere attestazioni aggiuntive tramite i percorsi utente di modifica del profilo. Ogni volta che Azure AD B2C raccoglie informazioni direttamente dall'utente in modo interattivo, il framework dell'esperienza di gestione delle identità usa il relativo selfasserted provider. I passaggi seguenti si applicano ogni volta che tale provider viene usato.

Definire l'attestazione, il nome visualizzato e il tipo di input utente

Per chiedere all'utente di indicare la propria città, aggiungere l'elemento seguente all'elemento <ClaimsSchema> nel file dei criteri TrustFrameWorkExtensions:

<ClaimType Id="city">
  <DisplayName>city</DisplayName>
  <DataType>string</DataType>
  <UserHelpText>Your city</UserHelpText>
  <UserInputType>TextBox</UserInputType>
</ClaimType>

Sono disponibili opzioni aggiuntive che è possibile definire qui per personalizzare l'attestazione. Per uno schema completo, vedere il documento Identity Experience Framework Technical Reference Guide (Guida di riferimento tecnico al framework dell'esperienza di gestione delle identità), che verrà presto pubblicata nella sezione dei riferimenti.

  • <DisplayName> è una stringa che definisce l'etichetta destinata all'utente.

  • <UserHelpText> consente all'utente di identificare i requisiti.

  • <UserInputType> include le quattro opzioni evidenziate di seguito.

    • TextBox

      <ClaimType Id="city">
      <DisplayName>city where you work</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Your city</UserHelpText>
      <UserInputType>TextBox</UserInputType>
      </ClaimType>
      
    • RadioSingleSelectduration applica una selezione singola.

      <ClaimType Id="city">
      <DisplayName>city where you work</DisplayName>
      <DataType>string</DataType>
      <UserInputType>RadioSingleSelect</UserInputType>
      <Restriction>
      <Enumeration Text="Bellevue" Value="bellevue" SelectByDefault="false" />
      <Enumeration Text="Redmond" Value="redmond" SelectByDefault="false" />
      <Enumeration Text="Kirkland" Value="kirkland" SelectByDefault="false" />
      </Restriction>
      </ClaimType>
      
    • DropdownSingleSelect consente di selezionare solo valori validi.

Screenshot dell'opzione nell'elenco a discesa

<ClaimType Id="city">
  <DisplayName>city where you work</DisplayName>
  <DataType>string</DataType>
  <UserInputType>DropdownSingleSelect</UserInputType>
  <Restriction>
    <Enumeration Text="Bellevue" Value="bellevue" SelectByDefault="false" />
    <Enumeration Text="Redmond" Value="redmond" SelectByDefault="false" />
    <Enumeration Text="Kirkland" Value="kirkland" SelectByDefault="false" />
  </Restriction>
</ClaimType>
  • CheckboxMultiSelect consente di selezionare uno o più valori.

Screenshot dell'opzione di selezione multipla

<ClaimType Id="city">
  <DisplayName>Receive updates from which cities?</DisplayName>
  <DataType>string</DataType>
  <UserInputType>CheckboxMultiSelect</UserInputType>
  <Restriction>
    <Enumeration Text="Bellevue" Value="bellevue" SelectByDefault="false" />
    <Enumeration Text="Redmond" Value="redmond" SelectByDefault="false" />
    <Enumeration Text="Kirkland" Value="kirkland" SelectByDefault="false" />
  </Restriction>
</ClaimType>

Aggiungere l'attestazione al percorso utente di iscrizione/accesso

  1. Aggiungere l'attestazione come <OutputClaim ClaimTypeReferenceId="city"/> all'oggetto TechnicalProfile LocalAccountSignUpWithLogonEmail incluso nel file dei criteri TrustFrameworkBase. Si noti che TechnicalProfile qui usa SelfAssertedAttributeProvider.

    <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
     <DisplayName>Email 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="language.button_continue">Create</Item>
     </Metadata>
     <CryptographicKeys>
       <Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" />
     </CryptographicKeys>
     <InputClaims>
       <InputClaim ClaimTypeReferenceId="email" />
     </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="givenName" />
       <OutputClaim ClaimTypeReferenceId="surName" />
       <OutputClaim ClaimTypeReferenceId="city"/>
     </OutputClaims>
     <ValidationTechnicalProfiles>
       <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
     </ValidationTechnicalProfiles>
     <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
    </TechnicalProfile>
    
  2. Aggiungere l'attestazione ad AAD-UserWriteUsingLogonEmail come <PersistedClaim ClaimTypeReferenceId="city" /> per scrivere l'attestazione nella directory di AAD dopo averla raccolta dall'utente. Se non si vuole mantenere l'attestazione nella directory per un uso futuro, è possibile ignorare questo passaggio.

    <!-- Technical profiles for local accounts -->
    <TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
     <Metadata>
       <Item Key="Operation">Write</Item>
       <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
     </Metadata>
     <IncludeInSso>false</IncludeInSso>
     <InputClaims>
       <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
     </InputClaims>
     <PersistedClaims>
       <!-- Required claims -->
       <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
       <PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password" />
       <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
       <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration" />
       <!-- Optional claims. -->
       <PersistedClaim ClaimTypeReferenceId="givenName" />
       <PersistedClaim ClaimTypeReferenceId="surname" />
       <PersistedClaim ClaimTypeReferenceId="city" />
     </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>
    
  3. Aggiungere l'attestazione all'oggetto TechnicalProfile che legge dalla directory quando un utente esegue l'accesso come <OutputClaim ClaimTypeReferenceId="city" />.

    <TechnicalProfile Id="AAD-UserReadUsingEmailAddress">
     <Metadata>
       <Item Key="Operation">Read</Item>
       <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
       <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">An account could not be found for the provided user ID.</Item>
     </Metadata>
     <IncludeInSso>false</IncludeInSso>
     <InputClaims>
       <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames" Required="true" />
     </InputClaims>
     <OutputClaims>
       <!-- Required claims -->
       <OutputClaim ClaimTypeReferenceId="objectId" />
       <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
       <!-- Optional claims -->
       <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
       <OutputClaim ClaimTypeReferenceId="displayName" />
       <OutputClaim ClaimTypeReferenceId="otherMails" />
       <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
       <OutputClaim ClaimTypeReferenceId="city" />
     </OutputClaims>
     <IncludeTechnicalProfile ReferenceId="AAD-Common" />
    </TechnicalProfile>
    
  4. Aggiungere <OutputClaim ClaimTypeReferenceId="city" /> al file dei criteri relying party SignUporSignIn.xml in modo che l'attestazione venga inviata all'applicazione nel token quando il percorso utente ha esito positivo.

    <RelyingParty>
     <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
     <TechnicalProfile Id="PolicyProfile">
       <DisplayName>PolicyProfile</DisplayName>
       <Protocol Name="OpenIdConnect" />
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="displayName" />
         <OutputClaim ClaimTypeReferenceId="givenName" />
         <OutputClaim ClaimTypeReferenceId="surname" />
         <OutputClaim ClaimTypeReferenceId="email" />
         <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
         <OutputClaim ClaimTypeReferenceId="identityProvider" />
         <OutputClaim ClaimTypeReferenceId="city" />
       </OutputClaims>
       <SubjectNamingInfo ClaimType="sub" />
     </TechnicalProfile>
    </RelyingParty>
    

Testare i criteri personalizzati tramite "Esegui adesso"

  1. Aprire il pannello Azure AD B2C e passare a Framework dell'esperienza di gestione delle identità > Criteri personalizzati.
  2. Selezionare il criterio personalizzato che è stato caricato e fare clic sul pulsante Esegui adesso.
  3. Dovrebbe essere possibile iscriversi usando un indirizzo di posta elettronica.

La schermata di iscrizione in modalità di test avrà un aspetto simile al seguente:

Screenshot dell'opzione di iscrizione modificata

Il token restituito all'applicazione ora include l'attestazione city, come illustrato di seguito.

{
  "exp": 1493596822,
  "nbf": 1493593222,
  "ver": "1.0",
  "iss": "https://login.microsoftonline.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "sub": "9c2a3a9e-ac65-4e46-a12d-9557b63033a9",
  "aud": "4e87c1dd-e5f5-4ac8-8368-bc6a98751b8b",
  "acr": "b2c_1a_trustf_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1493593222,
  "auth_time": 1493593222,
  "email": "joe@outlook.com",
  "given_name": "Joe",
  "family_name": "Ras",
  "city": "Bellevue",
  "name": "unknown"
}

Facoltativo: Rimuovere la verifica di posta elettronica dal percorso di iscrizione

Per ignorare la verifica di posta elettronica, l'autore dei criteri può scegliere di rimuovere PartnerClaimType="Verified.Email". L'indirizzo di posta elettronica verrà richiesto ma non verificato, a meno che "Required" = true non venga rimosso. Valutare attentamente se questa opzione è adatta ai casi d'uso.

La verifica di posta elettronica è abilitata per impostazione predefinita in <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail"> nel file dei criteri TrustFrameworkBase nel pacchetto iniziale:

<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />

Passaggi successivi

Aggiungere la nuova attestazione ai flussi per gli accessi con account di social networking modificando gli elementi TechnicalProfile elencati di seguito. Questi vengono usati per gli accessi con account di social networking/federati per scrivere e leggere i dati utente usando alternativeSecurityId come localizzatore.

<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">