Configurare xID con Azure Active Directory B2C per l'autenticazione senza password
Questa esercitazione descrive come integrare l'autenticazione di Azure Active Directory B2C (Azure AD B2C) con la soluzione xID digital ID. L'app xID fornisce agli utenti l'autenticazione senza password, sicura e multifactor. La scheda My Number, la scheda ID digitale rilasciata dal governo giapponese, verifica le identità utente autenticate xID. Per gli utenti, le organizzazioni possono ottenere informazioni di identificazione personale verificate (contenuto del cliente) tramite l'API xID. Inoltre, l'app xID genera una chiave privata in un'area sicura nei dispositivi mobili utente, rendendoli dispositivi di firma digitale.
Prerequisiti
Una sottoscrizione di Azure
- Se non ne è disponibile uno, è possibile ottenere un account gratuito di Azure
Un tenant di Azure AD B2C collegato alla sottoscrizione di Azure
Informazioni sul client xID fornite da xID inc.
Passare alla pagina xid.inc Contact Us per informazioni client xID:
- ID client
- Client Secret
- URL di reindirizzamento
- Ambiti
Passare a x-id.me per installare l'app xID in un dispositivo mobile:
- Scheda Numero personale
- Se si usa la versione UAT dell'API, ottenere la versione UAT dell'app xID. Vedere, Contattaci
Descrizione dello scenario
Il diagramma seguente illustra l'architettura.
- Nella pagina di accesso di Azure AD B2C l'utente accede o accede.
- Azure AD B2C reindirizza l'utente all'endpoint dell'API di autorizzazione xID usando una richiesta OIDC (OpenID Connect). Un endpoint OIDC include informazioni sull'endpoint. xID Identity Provider (IdP) reindirizza l'utente alla pagina di accesso di autorizzazione xID. L'utente immette l'indirizzo di posta elettronica.
- xID IdP invia una notifica push al dispositivo mobile dell'utente.
- L'utente apre l'app xID, controlla la richiesta, immette un PIN o usa la biometrica. l'app xID attiva la chiave privata e crea una firma elettronica.
- L'app xID invia la firma a xID IdP per la verifica.
- Viene visualizzata una schermata di consenso per fornire informazioni personali al servizio.
- xID IdP restituisce il codice di autorizzazione OAuth in Azure AD B2C.
- Azure AD B2C invia una richiesta di token usando il codice di autorizzazione.
- xID IdP controlla la richiesta del token. Se valido, viene restituito il token di accesso OAuth e il token ID con identificatore utente e indirizzo di posta elettronica.
- Se è necessario il contenuto del cliente utente, Azure AD B2C chiama l'API dati utente xID.
- L'API dati utente xID restituisce contenuto del cliente crittografato. Gli utenti decrittografano con una chiave privata, creata durante la richiesta di informazioni client xID.
- L'utente viene concesso o negato l'accesso all'applicazione del cliente.
Installare xID
- Per richiedere documenti API, compilare il modulo di richiesta. Vai a Contattaci.
- Nel messaggio indicare che si usa Azure AD B2C.
- Un rappresentante delle vendite xID contatta l'utente.
- Seguire le istruzioni nel documento dell'API xID.
- Richiedere un client API xID.
- il team tecnico xID invia informazioni client all'utente in 3-4 giorni lavorativi.
- Specificare un URI di reindirizzamento nel sito usando il modello seguente. Gli utenti tornano al sito dopo l'autenticazione.
https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp
Registrare un'applicazione Web in Azure AD B2C
Registrare le applicazioni in un tenant gestito, quindi possono interagire con Azure AD B2C.
Altre informazioni: Tipi di applicazione che possono essere usati in Active Directory B2C
Per i test, si registra https://jwt.ms, un'applicazione Web Microsoft con contenuto token decodificato, che non lascia il browser.
Registrare un'applicazione Web e abilitare la concessione implicita del token ID
Esercitazione completa: Registrare un'applicazione Web in Azure AD B2C
Creare una chiave dei criteri xID
Archiviare il segreto client da xID nel tenant di Azure AD B2C. Per le istruzioni seguenti, usare la directory con il tenant di Azure AD B2C.
- Accedere al portale di Azure.
- Nella barra degli strumenti del portale selezionare Directory e sottoscrizioni.
- Nelle impostazioni del portale | Directory e sottoscrizioni , nell'elenco Nomi directory individuare la directory B2C di Azure AD.
- Selezionare Commutatore.
- Nell'angolo superiore sinistro della portale di Azure selezionare Tutti i servizi.
- Cercare e selezionare Azure Active Directory B2C.
- In Panoramica selezionare Identity Experience Framework.
- Selezionare Chiavi dei criteri.
- Selezionare Aggiungi.
- Selezionare Manuale in Opzioni.
- Immettere un nome della chiave di criterio per la chiave dei criteri. Il prefisso
B2C_1A_viene aggiunto al nome della chiave. - In Segreto immettere il segreto client da xID.
- Per Uso chiave selezionare Firma.
- Selezionare Crea.
Nota
In Azure AD B2C i criteri personalizzati sono per scenari complessi.
Vedere La panoramica dei flussi utente e dei criteri personalizzati.
Configurare xID come provider di identità
Per consentire agli utenti di accedere usando xID, creare un provider di attestazioni con cui Azure AD B2C comunica tramite un endpoint. L'endpoint fornisce attestazioni che Azure AD B2C usa per verificare l'autenticazione degli utenti con identità digitale nel dispositivo.
Aggiungere xID come provider di attestazioni
Ottenere i pacchetti di avvio dei criteri personalizzati da GitHub, quindi aggiornare i file XML nel pacchetto di avvio SocialAccounts con il nome del tenant di Azure AD B2C.
Scaricare il file zip active-directory-b2c-policy-starterpack-main o clonare il repository. Vedere Azure-Samples/active-directory-b2c-custom-policy-starterpack.
Nei file nella directory SocialAccounts sostituire la stringa
yourtenantcon il nome del tenant di Azure AD B2C. Ad esempioyourtenant.onmicrosoft.comdiventacontoso.onmicrosoft.com.Aprire SocialAccounts/TrustFrameworkExtensions.xml.
Trovare l'elemento ClaimsProviders. Se non ne esiste uno, aggiungerlo sotto l'elemento radice.
Aggiungere un nuovo ClaimsProvider simile all'esempio seguente:
<ClaimsProvider> <Domain>X-ID</Domain> <DisplayName>X-ID</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="X-ID-OIDC"> <DisplayName>X-ID</DisplayName> <Description>Login with your X-ID account</Description> <Protocol Name="OpenIdConnect" /> <Metadata> <Item Key="METADATA">https://oidc-uat.x-id.io/.well-known/openid-configuration</Item> <!-- Update the Client ID below to the X-ID Application ID --> <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item> <Item Key="response_types">code</Item> <Item Key="scope">openid verification</Item> <Item Key="response_mode">query</Item> <Item Key="HttpBinding">POST</Item> <Item Key="UsePolicyInRedirectUri">false</Item> <Item Key="DiscoverMetadataByTokenIssuer">true</Item> <Item Key="token_endpoint_auth_method">client_secret_basic</Item> <Item Key="ClaimsEndpoint">https://oidc-uat.x-id.io/userinfo</Item> <Item Key="ValidTokenIssuerPrefixes">https://oidc-uat.x-id.io/</Item> </Metadata> <CryptographicKeys> <Key Id="client_secret" StorageReferenceId="B2C_1A_XIDSecAppSecret" /> </CryptographicKeys> <OutputClaims> <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" /> <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" /> <OutputClaim ClaimTypeReferenceId="email" /> <OutputClaim ClaimTypeReferenceId="sid" /> <OutputClaim ClaimTypeReferenceId="userdataid" /> <OutputClaim ClaimTypeReferenceId="XID_verified" /> <OutputClaim ClaimTypeReferenceId="email_verified" /> <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" /> <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://oidc-uat.x-id.io/" /> <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" /> </OutputClaims> <OutputClaimsTransformations> <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" /> <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" /> <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" /> <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" /> </OutputClaimsTransformations> <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" /> </TechnicalProfile> <TechnicalProfile Id="X-ID-Userdata"> <DisplayName>Userdata (Personal Information)</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="ServiceUrl">https://api-uat.x-id.io/v4/verification/userdata</Item> <Item Key="SendClaimsIn">Header</Item> <Item Key="AuthenticationType">Bearer</Item> <Item Key="UseClaimAsBearerToken">identityProviderAccessToken</Item> <!-- <Item Key="AllowInsecureAuthInProduction">true</Item> --> <Item Key="DebugMode">true</Item> <Item Key="DefaultUserMessageIfRequestFailed">Can't process your request right now, please try again later.</Item> </Metadata> <InputClaims> <!-- Claims sent to your REST API --> <InputClaim ClaimTypeReferenceId="identityProviderAccessToken" /> </InputClaims> <OutputClaims> <!-- Claims parsed from your REST API --> <OutputClaim ClaimTypeReferenceId="last_name" /> <OutputClaim ClaimTypeReferenceId="first_name" /> <OutputClaim ClaimTypeReferenceId="previous_name" /> <OutputClaim ClaimTypeReferenceId="year" /> <OutputClaim ClaimTypeReferenceId="month" /> <OutputClaim ClaimTypeReferenceId="date" /> <OutputClaim ClaimTypeReferenceId="prefecture" /> <OutputClaim ClaimTypeReferenceId="city" /> <OutputClaim ClaimTypeReferenceId="address" /> <OutputClaim ClaimTypeReferenceId="sub_char_common_name" /> <OutputClaim ClaimTypeReferenceId="sub_char_previous_name" /> <OutputClaim ClaimTypeReferenceId="sub_char_address" /> <OutputClaim ClaimTypeReferenceId="gender" /> <OutputClaim ClaimTypeReferenceId="verified_at" /> </OutputClaims> <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" /> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>Impostare client_id con l'ID applicazione xID.
Selezionare Salva.
Aggiungere un percorso utente
Aggiungere un provider di identità alle pagine di accesso.
- Se si dispone di un percorso utente personalizzato, passare a Aggiungere il provider di identità a un percorso utente. In caso contrario, creare un duplicato di un percorso utente modello:
- Dal starter pack aprire il TrustFrameworkBase.xml.
- Individuare e copiare il contenuto dell'elemento UserJourneys che include
ID=SignUpOrSignIn. - Aprire il TrustFrameworkExtensions.xml e individuare l'elemento UserJourneys. Se non ne esiste uno, aggiungerne uno.
- Incollare il contenuto dell'elemento UserJourney come elemento figlio dell'elemento UserJourneys.
- Rinominare l'ID percorso utente. Ad esempio:
ID=CustomSignUpSignIn
Aggiungere il provider di identità a un percorso utente
Aggiungere il nuovo provider di identità al percorso utente.
- Individuare l'elemento del passaggio di orchestrazione con Type=
CombinedSignInAndSignUpo Type=ClaimsProviderSelectionnel percorso utente. In genere è il primo passaggio di orchestrazione. L'elemento ClaimsProviderSelections include un elenco di provider di identità per l'accesso. L'ordine degli elementi controlla l'ordine dei pulsanti di accesso. - Aggiungere un elemento XML ClaimsProviderSelection .
- Impostare il valore di TargetClaimsExchangeId su un nome descrittivo.
- Aggiungere un elemento ClaimsExchange .
- Impostare l'ID sul valore dell'ID dello scambio di attestazioni di destinazione. Questa modifica collega il pulsante xID all'azione
X-IDExchange. - Aggiornare il valore TechnicalProfileReferenceId all'ID profilo tecnico creato (
X-ID-OIDC). - Aggiungere un passaggio di orchestrazione per chiamare l'endpoint userInfo xID per restituire attestazioni sull'utente
X-ID-Userdataautenticato.
Il codice XML seguente illustra l'orchestrazione del percorso utente con il provider di identità xID.
<UserJourney Id="CombinedSignInAndSignUp">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
<ClaimsProviderSelections>
<ClaimsProviderSelection TargetClaimsExchangeId="X-IDExchange" />
</ClaimsProviderSelections>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="X-IDExchange" TechnicalProfileReferenceId="X-ID-OIDC" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="X-ID-Userdata" TechnicalProfileReferenceId="X-ID-Userdata" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- For social IDP authentication, attempt to find the user account in the directory. -->
<OrchestrationStep Order="4" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). -->
<OrchestrationStep Order="5" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect
from the user. So, in that case, create the user in the directory if one does not already exist
(verified using objectId which would be set from the last step if account was created in the directory. -->
<OrchestrationStep Order="6" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
<ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>
Sono supportate attestazioni di identità xID a cui viene fatto riferimento come parte dei criteri. Lo schema delle attestazioni è il percorso in cui si dichiarano le attestazioni. L'elemento ClaimsSchema include un elenco di elementi ClaimType. L'elemento ClaimType contiene l'attributo ID, ovvero il nome dell'attestazione.
- Aprire il TrustFrameworksExtension.xml.
- Individuare l'elemento BuildingBlocks .
- Aggiungere l'elemento ClaimType seguente nell'elemento ClaimsSchema del criterio diTrustFrameworksExtension.xml
<BuildingBlocks>
<ClaimsSchema>
<!-- xID -->
<ClaimType Id="sid">
<DisplayName>sid</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="userdataid">
<DisplayName>userdataid</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="xid_verified">
<DisplayName>xid_verified</DisplayName>
<DataType>boolean</DataType>
</ClaimType>
<ClaimType Id="email_verified">
<DisplayName>email_verified</DisplayName>
<DataType>boolean</DataType>
</ClaimType>
<ClaimType Id="identityProviderAccessToken">
<DisplayName>Identity Provider Access Token</DisplayName>
<DataType>string</DataType>
<AdminHelpText>Stores the access token of the identity provider.</AdminHelpText>
</ClaimType>
<ClaimType Id="last_name">
<DisplayName>last_name</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="first_name">
<DisplayName>first_name</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="previous_name">
<DisplayName>previous_name</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="year">
<DisplayName>year</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="month">
<DisplayName>month</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="date">
<DisplayName>date</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="prefecture">
<DisplayName>prefecture</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="city">
<DisplayName>city</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="address">
<DisplayName>address</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="sub_char_common_name">
<DisplayName>sub_char_common_name</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="sub_char_previous_name">
<DisplayName>sub_char_previous_name</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="sub_char_address">
<DisplayName>sub_char_address</DisplayName>
<DataType>string</DataType>
</ClaimType>
<ClaimType Id="verified_at">
<DisplayName>verified_at</DisplayName>
<DataType>int</DataType>
</ClaimType>
<ClaimType Id="gender">
<DisplayName>Gender</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name="OpenIdConnect" PartnerClaimType="gender" />
</DefaultPartnerClaimTypes>
<AdminHelpText>The user's gender.</AdminHelpText>
<UserHelpText>Your gender.</UserHelpText>
<UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="correlationId">
<DisplayName>correlation ID</DisplayName>
<DataType>string</DataType>
</ClaimType>
<!-- xID -->
</ClaimsSchema>
</BuildingBlocks>
Configurare i criteri della relying party
I criteri della relying party, ad esempio SignUpSignIn.xml, specificano il percorso utente eseguito da Azure AD B2C.
- Nella relying party individuare l'elemento DefaultUserJourney .
- Aggiornare il ReferenceId in modo che corrisponda all'ID percorso utente aggiunto al provider di identità.
Nell'esempio seguente, per il percorso utente xID, ReferenceId è impostato su CombinedSignInAndSignUp.
<RelyingParty>
<DefaultUserJourney ReferenceId="CombinedSignInAndSignUp" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
<OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
<OutputClaim ClaimTypeReferenceId="issuerUserId" />
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
<OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="last_name" />
<OutputClaim ClaimTypeReferenceId="previous_name" />
<OutputClaim ClaimTypeReferenceId="year" />
<OutputClaim ClaimTypeReferenceId="month" />
<OutputClaim ClaimTypeReferenceId="date" />
<OutputClaim ClaimTypeReferenceId="prefecture" />
<OutputClaim ClaimTypeReferenceId="city" />
<OutputClaim ClaimTypeReferenceId="address" />
<OutputClaim ClaimTypeReferenceId="sub_char_common_name" />
<OutputClaim ClaimTypeReferenceId="sub_char_previous_name" />
<OutputClaim ClaimTypeReferenceId="sub_char_address" />
<OutputClaim ClaimTypeReferenceId="gender" />
<OutputClaim ClaimTypeReferenceId="verified_at" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="sid" />
<OutputClaim ClaimTypeReferenceId="userdataid" />
<OutputClaim ClaimTypeReferenceId="xid_verified" />
<OutputClaim ClaimTypeReferenceId="email_verified" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Caricare il criterio personalizzati
Per le istruzioni seguenti, usare la directory con il tenant di Azure AD B2C.
- Accedere al portale di Azure.
- Nella barra degli strumenti del portale selezionare Directory e sottoscrizioni.
- Nelle impostazioni del portale | Pagina Directory e sottoscrizioni nell'elenco Nome directory . individuare la directory di Azure AD B2C.
- Selezionare Cambia.
- Nella portale di Azure cercare e selezionare Azure AD B2C.
- In Criteri selezionare Identity Experience Framework.
- Selezionare Carica criteri personalizzati.
- Caricare i file nell'ordine seguente:
- File dei criteri di base:
TrustFrameworkBase.xml - Criteri di estensione:
TrustFrameworkExtensions.xml - Criteri relying party:
SignUpSignIn.xml
Testare i criteri personalizzati
- Nel tenant di Azure AD B2C e in Criteri selezionare Identity Experience Framework.
- In Criteri personalizzati selezionare CustomSignUpSignIn.
- In Applicazione selezionare l'applicazione Web registrata. L'URL di risposta è
https://jwt.ms. - Selezionare Esegui adesso.
- Il browser reindirizza alla pagina di accesso xID.
- Il browser reindirizza a
https://jwt.ms. Viene visualizzato il contenuto del token restituito da Azure AD B2C.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per