Condividi tramite


Configurare l'iscrizione e l'accesso con il provider di identità SAML usando Azure Active Directory B2C

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.

Azure Active Directory B2C (Azure AD B2C) supporta la federazione con i provider di identità SAML 2.0. Questo articolo illustra come abilitare l'accesso con un account utente del provider di identità SAML, consentendo agli utenti di accedere con le identità aziendali o di social networking esistenti, ad esempio ADFS e Salesforce.

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.

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

Panoramica dello scenario

È possibile configurare Azure AD B2C per consentire agli utenti di accedere all'applicazione con le credenziali di provider di identità SAML (IdP) esterni o aziendali. Quando Azure AD B2C esegue la federazione con un provider di identità SAML, funge da provider di servizi avviando una richiesta SAML al provider di identità SAML e attendendo una risposta SAML. Nel diagramma seguente:

  1. L'applicazione avvia una richiesta di autorizzazione ad Azure AD B2C. L'applicazione può essere un'applicazione OAuth 2.0 o OpenId Connect o un provider di servizi SAML.
  2. Nella pagina di accesso di Azure AD B2C l'utente sceglie di accedere con un account del provider di identità SAML( ad esempio , Contoso). Azure AD B2C avvia una richiesta di autorizzazione SAML e porta l'utente al provider di identità SAML per completare l'accesso.
  3. Il fornitore di identità SAML restituisce una risposta SAML.
  4. Azure AD B2C convalida il token SAML, estrae attestazioni, rilascia il proprio token e riporta l'utente all'applicazione.

Accedere al flusso del provider di identità SAML

Prerequisiti

Componenti della soluzione

Per questo scenario sono necessari i componenti seguenti:

  • Un provider di identità SAML con la possibilità di ricevere, decodificare e rispondere alle richieste SAML da Azure AD B2C.
  • Un endpoint dei metadati SAML disponibile pubblicamente per il tuo provider di identità.
  • Un tenant di Azure AD B2C.

Importante

Gli endpoint devono essere conformi ai requisiti di sicurezza di Azure AD B2C. Le versioni precedenti di TLS e le crittografie sono deprecate. Per altre informazioni, vedere Requisiti di Azure AD B2C TLS e della suite di crittografia.

Creare una chiave dei criteri

Per stabilire un trust tra Azure AD B2C e il provider di identità SAML, è necessario fornire un certificato X509 valido con la chiave privata. Azure AD B2C firma le richieste SAML usando la chiave privata del certificato. Il provider di identità convalida la richiesta usando la chiave pubblica del certificato. La chiave pubblica è accessibile tramite i metadati del profilo tecnico. In alternativa, è possibile caricare manualmente il file di .cer nel provider di identità SAML.

Un certificato autofirmato è accettabile per la maggior parte degli scenari. Per gli ambienti di produzione, è consigliabile usare un certificato X509 emesso da un'autorità di certificazione. Inoltre, come descritto più avanti in questo documento, per un ambiente non di produzione è possibile disabilitare la firma SAML su entrambi i lati.

Ottenere un certificato

Se non si ha già un certificato, per questa esercitazione è possibile usarne uno autofirmato. Un certificato autofirmato è un certificato di sicurezza non firmato da un'autorità di certificazione (CA) e non fornisce le garanzie di sicurezza di un certificato firmato da una CA.

In Windows usare il cmdlet New-SelfSignedCertificate in PowerShell per generare un certificato.

  1. Eseguire il seguente comando di PowerShell per generare un certificato autofirmato. Modificare -Subjectl'argomento in base al nome dell'applicazione e del tenant Azure AD B2C, come contosowebapp.contoso.onmicrosoft.com. Si può anche modificare la data -NotAfter per specificare una scadenza diversa per il certificato.

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. Nel computer Windows, cercare e selezionare l'opzione Gestisci certificati utente

  3. In Certificati - Utente corrente, selezionare personali>Certificati>yourappname.yourtenant.onmicrosoft.com.

  4. Selezionare il certificato e quindi selezionare Azione>Tutte le attività>Esporta.

  5. Selezionare Avanti>Sì, esportare la chiave> privataAvanti.

  6. Accettare le impostazioni predefinite per Formato file di esportazione e quindi selezionare Avanti.

  7. Abilitare l'opzione Password , immettere una password per il certificato e quindi selezionare Avanti.

  8. Per specificare un percorso per salvare il certificato, selezionare Sfoglia e passare a una directory di propria scelta.

  9. Nella finestra Salva con nome immettere un nome file e quindi selezionare Salva.

  10. Selezionare Avanti>Fine.

Per consentire ad Azure AD B2C di accettare la password del file pfx, la password deve essere crittografata con l'opzione TripleDES-SHA1 nell'utilità di esportazione dell'Archivio certificati di Windows, anziché AES256-SHA256.

Caricare il certificato

È necessario archiviare il certificato nel tenant di Azure AD B2C.

  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. Nella pagina Panoramica selezionare Identity Experience Framework.
  5. Selezionare Chiavi dei criteri e quindi selezionare Aggiungi.
  6. Per Opzioni scegliere Upload.
  7. Immettere un nome per la chiave della politica. Ad esempio: SAMLSigningCert. Il prefisso B2C_1A_ viene aggiunto automaticamente al nome della chiave.
  8. Per accedere al file .pfx del certificato con la chiave privata e selezionarlo.
  9. Clicca su Crea.

Configurare il profilo tecnico SAML

Definire il provider di identità SAML aggiungendolo all'elemento ClaimsProviders nel file di estensione dei criteri. I provider di attestazioni includono un profilo tecnico SAML che stabilisce gli endpoint e i protocolli necessari per comunicare con il provider di identità SAML. Per aggiungere un provider di attestazioni con un profilo tecnico SAML:

  1. Aprire il TrustFrameworkExtensions.xml.

  2. Trova l'elemento ClaimsProviders. Se non esiste, aggiungerlo sotto l'elemento radice.

  3. Aggiungere un nuovo ClaimsProvider come segue:

    <ClaimsProvider>
      <Domain>Contoso.com</Domain>
      <DisplayName>Contoso</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Contoso-SAML2">
          <DisplayName>Contoso</DisplayName>
          <Description>Login with your SAML identity provider account</Description>
          <Protocol Name="SAML2"/>
          <Metadata>
            <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="assertionSubjectName" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="http://schemas.microsoft.com/identity/claims/displayname" />
            <OutputClaim ClaimTypeReferenceId="email"  />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    

Aggiornare gli elementi XML seguenti con il valore pertinente:

Elemento XML Valore
FornitoreDiReclami\Dominio Nome di dominio usato per l'accesso diretto. Immettere il nome di dominio che si vuole usare nell'accesso diretto. Ad esempio, Contoso.com.
TechnicalProfile\DisplayName Questo valore verrà visualizzato nel pulsante di accesso nella schermata di accesso. Ad esempio, Contoso.
Metadati\PartnerEntity URL dei metadati del provider di identità SAML. In alternativa, è possibile copiare i metadati del provider di identità e aggiungerli all'interno dell'elemento <![CDATA[Your IDP metadata]]>CDATA .

Mappare le affermazioni

L'elemento OutputClaims contiene un elenco di attestazioni restituite dal provider di identità SAML. Associare il nome della rivendicazione definita nella politica al nome dell'asserzione definito nel provider di identità. Controllare il provider di identità per l'elenco delle attestazioni (asserzioni). Per ulteriori informazioni, vedere mappatura delle attestazioni.

Nell'esempio precedente Contoso-SAML2 include le attestazioni restituite da un provider di identità SAML:

  • L'attestazione assertionSubjectName viene mappata all'attestazione issuerUserId.
  • L'attestazione first_name viene mappata all'attestazione givenName.
  • L'attestazione last_name viene mappata all'attestazione di cognome.
  • L'attestazione http://schemas.microsoft.com/identity/claims/displayname viene mappata all'attestazione displayName .
  • Dichiarazione di email senza mappatura del nome.

Il profilo tecnico restituisce anche attestazioni che non vengono restituite dal provider di identità:

  • La dichiarazione identityProvider che contiene il nome del fornitore di identità.
  • Attestazione authenticationSource con il valore predefinito socialIdpAuthentication.

Aggiungere il profilo tecnico della sessione SAML

Se non hai già il profilo tecnico della SM-Saml-idp sessione SAML, aggiungilo alla policy di estensione. Individuare la <ClaimsProviders> sezione e aggiungere il frammento XML seguente. Se la tua politica contiene già il SM-Saml-idp profilo tecnico, vai al passaggio successivo. Per altre informazioni, vedere Gestione delle sessioni single sign-on.

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-Saml-idp">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IncludeSessionIndex">false</Item>
        <Item Key="RegisterServiceProviders">false</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Aggiungere un percorso utente

A questo punto, il fornitore dell'identità è stato configurato, ma non è ancora disponibile in nessuna delle pagine di accesso. Se non si ha un percorso utente personalizzato, creare un duplicato di un percorso utente modello esistente, altrimenti continuare con il passaggio successivo.

  1. Aprire il fileTrustFrameworkBase.xml dallo starter pack.
  2. Trovare e copiare l'intero contenuto dell'elemento UserJourney che include Id="SignUpOrSignIn".
  3. Aprire il TrustFrameworkExtensions.xml e trovare l'elemento UserJourneys . Se l'elemento non esiste, aggiungerne uno.
  4. Incollare l'intero contenuto dell'elemento UserJourney copiato come elemento figlio dell'elemento UserJourneys .
  5. Rinominare l'ID del percorso utente. Ad esempio: Id="CustomSignUpSignIn".

Aggiungere il fornitore di identità a un percorso dell'utente

Dopo aver creato un percorso utente, aggiungere il nuovo provider di identità al percorso utente. Aggiungere prima un pulsante di accesso, quindi collegare il pulsante a un'azione. L'azione è il profilo tecnico creato in precedenza.

  1. Trovare l'elemento del passaggio di orchestrazione che include Type="CombinedSignInAndSignUp"o Type="ClaimsProviderSelection" nel percorso utente. In genere è il primo passaggio di orchestrazione. L'elemento ClaimsProviderSelections contiene un elenco di provider di identità con cui un utente può accedere. L'ordine degli elementi controlla l'ordine dei pulsanti di accesso presentati all'utente. Aggiungere un elemento XML ClaimsProviderSelection . Impostare il valore di TargetClaimsExchangeId su un nome amichevole.

  2. Nel passaggio di orchestrazione successivo aggiungere un elemento ClaimsExchange . Impostare ID sul valore dell'ID di scambio di attestazioni di destinazione. Aggiornare il valore di TechnicalProfileReferenceId sull'ID del profilo tecnico creato in precedenza.

Il codice XML seguente illustra i primi due passaggi di orchestrazione di un percorso utente con il provider di identità:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
  </ClaimsExchanges>
</OrchestrationStep>

Configurare i criteri della relying party

I criteri della relying party, ad esempio SignUpSignIn.xml, specificano il percorso utente che verrà eseguito da Azure AD B2C. Trovare l'elemento DefaultUserJourney all'interno della relying party. Aggiorna ReferenceId affinché corrisponda all'ID del percorso utente in cui hai aggiunto il provider di identità.

Nell'esempio seguente, per il CustomSignUpSignIn percorso utente, ReferenceId è impostato su CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Caricare i criteri personalizzati

  1. Accedi al portale di Azure.
  2. Selezionare l'icona Directory e sottoscrizione nella barra degli strumenti del portale e quindi selezionare la directory che contiene il tenant di Azure AD B2C.
  3. Nel portale di Azure cercare e selezionare Azure AD B2C.
  4. Sotto Politiche, selezionare Identity Experience Framework.
  5. Selezionare Carica criteri personalizzati e quindi caricare i due file di criteri modificati, nell'ordine seguente: il criterio di estensione, ad esempio TrustFrameworkExtensions.xml, quindi il criterio della parte fiduciante, come SignUpSignIn.xml.

Configurare il tuo provider di identità SAML

Dopo aver configurato i criteri, è necessario configurare il provider di identità SAML con i metadati SAML di Azure AD B2C. I metadati SAML sono informazioni usate nel protocollo SAML per esporre la configurazione della tua politica, cioè il fornitore di servizi. Definisce la posizione dei servizi, come accesso e disconnessione, certificati, metodo di autenticazione, e altro ancora.

Ogni provider di identità SAML prevede passaggi diversi per l'impostazione di un provider di servizi. Alcuni provider di identità SAML richiedono i metadati di Azure AD B2C, mentre altri chiedono di esaminare manualmente il file di metadati per fornire le informazioni. Consulta la documentazione del tuo fornitore di identità per ulteriori indicazioni.

L'esempio seguente mostra un indirizzo URL per i metadati SAML di un profilo tecnico di Azure AD B2C:

https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<your-policy>/samlp/metadata?idptp=<your-technical-profile>

Quando si usa un dominio personalizzato, usare il formato seguente:

https://your-domain-name/<your-tenant-name>.onmicrosoft.com/<your-policy>/samlp/metadata?idptp=<your-technical-profile>

Sostituire i valori seguenti:

  • Sostituisci your-tenant-name con il nome del tuo tenant, ad esempio your-tenant.onmicrosoft.com.
  • your-domain-name con il nome di dominio personalizzato, ad esempio login.contoso.com.
  • your-policy con il nome della tua policy. Ad esempio, B2C_1A_signup_signin_adfs.
  • il tuo profilo tecnico con il nome del tuo profilo tecnico del provider di identità SAML. Ad esempio, Contoso-SAML2.

Aprire un browser e passare all'URL. Assicurarsi di digitare l'URL corretto e di avere accesso al file di metadati XML.

Metti alla prova la tua politica personalizzata.

  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. Nel portale di Azure cercare e selezionare Azure AD B2C.
  4. Sotto Criteri, selezionare Identity Experience Framework
  5. Seleziona i criteri della tua parte fidata, ad esempio B2C_1A_signup_signin.
  6. In Applicazione selezionare un'applicazione Web registrata in precedenza. L'URL di risposta dovrebbe mostrare https://jwt.ms.
  7. Selezionare il pulsante Esegui adesso .
  8. Nella pagina di iscrizione o accesso selezionare Contoso per accedere con l'account Contoso.

Se il processo di accesso ha esito positivo, il browser viene reindirizzato a https://jwt.ms, che visualizza il contenuto del token restituito da Azure AD B2C.

Passaggi successivi