Condividi tramite

Aggiungere AD FS come provider di identità SAML usando criteri personalizzati in Azure Active Directory B2C

  • Articolo

Prima di iniziare, usare il selettore Scegli un tipo di criterio 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.

Nota

In Azure Active Directory B2C i criteri personalizzati sono stati progettati principalmente per far fronte a scenari complessi. Per la maggior parte degli scenari, è consigliabile usare i flussi utente predefiniti. In caso contrario, vedere Introduzione ai criteri personalizzati in Active Directory B2C.

Questo articolo illustra come abilitare l'accesso per un account utente AD FS usando criteri personalizzati in Azure Active Directory B2C (Azure AD B2C). Per abilitare l'accesso, aggiungere un provider di identità SAML a un criterio personalizzato.

Prerequisiti

Creare un certificato autofirmato

Se non si ha già un certificato, è possibile usare un certificato 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 comando di PowerShell seguente per generare un certificato autofirmato. Modificare l'argomento -Subject in base alle esigenze dell'applicazione e del nome del tenant di Azure AD B2C, contosowebapp.contoso.onmicrosoft.comad esempio . 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 Gestisci certificati utente

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

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

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

  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 Next>Finish (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.

Creare una chiave dei criteri

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

  1. Accedi al portale di Azure.
  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.
  3. Scegliere Tutti i servizi nell'angolo in alto a sinistra nel portale di Azure e quindi cercare e selezionare Azure AD B2C.
  4. Nella pagina Panoramica selezionare Framework dell'esperienza di gestione delle identità.
  5. Selezionare Chiavi dei criteri e quindi selezionare Aggiungi.
  6. Per Opzioni scegliere Upload.
  7. Immettere un nome per la chiave dei criteri. Ad esempio, SAMLSigningCert. Verrà aggiunto automaticamente il prefisso B2C_1A_ al nome della chiave.
  8. Individuare e selezionare il file di certificato con estensione pfx con la chiave privata.
  9. Fai clic su Crea.

Aggiungere un provider di attestazioni

Per consentire agli utenti di accedere usando un account AD FS, è necessario definire l'account come provider di attestazioni con cui Azure AD B2C può comunicare tramite un endpoint. L'endpoint offre un set di attestazioni che vengono usate da Azure AD B2C per verificare se un utente specifico è stato autenticato.

È possibile definire un account AD FS come provider di attestazioni aggiungendolo all'elemento ClaimsProviders nel file di estensione dei criteri. Per altre informazioni, vedere Definire un provider di identità SAML.

  1. Aprire TrustFrameworkExtensions.xml.

  2. Trovare l'elemento ClaimsProviders. Se non esiste, aggiungerlo nell'elemento radice.

  3. Aggiungere un nuovo ClaimsProvider come illustrato di seguito:

    <ClaimsProvider>
  <Domain>contoso.com</Domain>
  <DisplayName>Contoso</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Contoso-SAML2">
      <DisplayName>Contoso</DisplayName>
      <Description>Login with your AD FS account</Description>
      <Protocol Name="SAML2"/>
      <Metadata>
        <Item Key="WantsEncryptedAssertions">false</Item>
        <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="userPrincipalName" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/>
        <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>

  4. Sostituire your-AD-FS-domain con il nome del dominio AD FS e sostituire il valore dell'attestazione di output identityProvider con il DNS (valore arbitrario che indica il dominio).

  5. Individuare la sezione <ClaimsProviders> e aggiungere il frammento XML seguente. Se il criterio contiene già il profilo tecnico SM-Saml-idp, andare 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>

  6. Salva il file.

Aggiungere un percorso utente

A questo punto, il provider di 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 file TrustFrameworkBase.xml dallo starter pack.
  2. Trovare e copiare l'intero contenuto dell'elemento UserJourney che include Id="SignUpOrSignIn".
  3. Aprire TrustFrameworkExtensions.xml e trovare l'elemento UserJourneys. Se l'elemento non esiste, aggiungerne uno.
  4. Incollare l'intero contenuto dell'elemento UserJourney copiato come figlio dell'elemento UserJourneys.
  5. Rinominare l'ID del percorso utente. Ad esempio, Id="CustomSignUpSignIn".

Aggiungere il provider di identità a un percorso 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 descrittivo.

  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. Aggiornare ReferenceId in modo che corrisponda all'ID percorso utente in cui è stato aggiunto il provider di identità.

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

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

Caricare il criterio personalizzati

  1. Accedi al portale di Azure.
  2. Selezionare l'icona Directory e sottoscrizione nella barra degli strumenti del portale e quindi la directory contenente il tenant di Azure AD B2C.
  3. Nel portale di Azure cercare e selezionare Azure AD B2C.
  4. In Criteri selezionare Identity Experience Framework.
  5. Selezionare Carica criteri personalizzati e quindi caricare i due file di criteri modificati, nell'ordine seguente: i criteri di estensione, ad esempio , quindi i criteri della relying party, ad esempio TrustFrameworkExtensions.xmlSignUpSignIn.xml.

Configurare un trust della relying party di AD FS

Per usare AD FS come provider di identità in Azure AD B2C, è necessario creare un trust della relying party ad AD FS con i metadati SAML di Azure AD B2C. L'esempio seguente mostra un indirizzo URL che punta ai 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:

  • nome-tenant con il nome del tenant, ad esempio your-tenant.onmicrosoft.com.
  • nome di dominio con il nome di dominio personalizzato, ad esempio login.contoso.com.
  • your-policy con il nome dei criteri. Ad esempio, B2C_1A_signup_signin_adfs.
  • profilo tecnico con il nome del 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 dei metadati XML. Per aggiungere un nuovo trust della relying party usando lo snap-in di gestione di AD FS e configurare manualmente le impostazioni, eseguire la procedura seguente in un server federativo. L'appartenenza al gruppo Amministratori o a un gruppo equivalente nel computer locale è il requisito minimo necessario per completare questa procedura.

  1. In Server Manager, seleziona Strumenti, quindi seleziona Gestione AD FS.

  2. Seleziona Aggiungi attendibilità componente.

  3. Nella pagina iniziale scegliere Attestazioni in grado di riconoscere le attestazioni e quindi selezionare Avvia.

  4. Nella pagina Selezione origine dati selezionare Importa dati sulla relying party pubblica online o in una rete locale, specificare l'URL dei metadati di Azure AD B2C e quindi selezionare Avanti.

  5. Nella pagina Specifica nome visualizzato immettere un nome visualizzato, in Note immettere una descrizione per l'attendibilità della relying party e quindi selezionare Avanti.

  6. Nella pagina Scegli criteri Controllo di accesso selezionare un criterio e quindi selezionare Avanti.

  7. Nella pagina Pronto per aggiungere attendibilità esaminare le impostazioni e quindi selezionare Avanti per salvare le informazioni sull'attendibilità della relying party.

  8. Nella pagina Fine selezionare Chiudi. Questa azione visualizza automaticamente la finestra di dialogo Modifica regole attestazione .

  9. Seleziona Aggiungi regola.

  10. In Modello di regola attestazione selezionare Inviare attributi LDAP come attestazioni.

  11. Specificare un nome in Nome regola attestazione. Per Archivio attributi selezionare Seleziona Active Directory, aggiungere le attestazioni seguenti, quindi selezionare Fine e OK.

    Attributo LDAP Tipo di attestazione in uscita
    Nome dell'entità utente userPrincipalName
    Surname family_name
    Given-Name given_name
    E-Mail-Address posta elettronica
    Display-Name name

    Si noti che alcuni nomi non verranno visualizzati nell'elenco a discesa tipo di attestazione in uscita. È necessario digitarli manualmente. L'elenco a discesa è modificabile.

  12. In base al tipo di certificato è possibile che sia necessario impostare l'algoritmo HASH. Nella finestra delle proprietà trust della relying party (B2C Demo) selezionare la scheda Avanzate e impostare Secure hash algorithm ( SHA-256Algoritmo hash sicuro) su e selezionare OK.

  13. In Server Manager, seleziona Strumenti, quindi seleziona Gestione AD FS.

  14. Selezionare l'attendibilità della relying party creata, selezionare Aggiorna dai metadati della federazione e quindi selezionare Aggiorna.

Testare i criteri personalizzati

  1. Accedi al portale di Azure.
  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.
  3. Nel portale di Azure cercare e selezionare Azure AD B2C.
  4. In Criteri selezionare Framework dell'esperienza di gestione delle identità
  5. Selezionare i criteri della relying party, 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 AD FS per accedere con il provider di identità Contoso AD FS .

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.

Risoluzione dei problemi del servizio AD FS

AD FS è configurato per l'uso del registro applicazioni di Windows. Se si verificano problemi durante la configurazione di AD FS come provider di identità SAML usando criteri personalizzati in Azure AD B2C, è consigliabile controllare il registro eventi di AD FS:

  1. Nella barra di Windows Search digitare Visualizzatore eventi e quindi selezionare l'app desktop Visualizzatore eventi.
  2. Per visualizzare il registro di un altro computer, fare clic con il pulsante destro del mouse su Visualizzatore eventi (locale). Scegliere Connetti a un altro computer, quindi immettere le informazioni necessarie nella finestra di dialogo Selezione computer.
  3. In Visualizzatore eventi aprire Registri applicazioni e servizi.
  4. Selezionare AD FS, quindi selezionare Amministrazione.
  5. Per visualizzare ulteriori informazioni su un evento, fare doppio clic sull'evento stesso.

La richiesta SAML non è firmata con l'evento dell'algoritmo di firma previsto

Questo errore indica che la richiesta SAML inviata da Azure AD B2C non è firmata con l'algoritmo di firma previsto configurato in AD FS. Ad esempio, la richiesta SAML viene firmata con l'algoritmo rsa-sha256di firma , ma l'algoritmo di firma previsto è rsa-sha1. Per risolvere questo problema, assicurarsi che Sia Azure AD B2C che AD FS siano configurati con lo stesso algoritmo di firma.

Opzione 1: Impostare l'algoritmo di firma in Azure AD B2C

È possibile configurare come firmare la richiesta SAML in Azure AD B2C. I metadati XmlSignatureAlgorithm controllano il valore del SigAlg parametro (stringa di query o parametro post) nella richiesta SAML. L'esempio seguente configura Azure AD B2C per l'uso dell'algoritmo di rsa-sha256 firma.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="XmlSignatureAlgorithm">Sha256</Item>
</Metadata>

Opzione 2: Impostare l'algoritmo di firma in AD FS

In alternativa, è possibile configurare l'algoritmo di firma della richiesta SAML previsto in AD FS.

  1. In Server Manager, seleziona Strumenti, quindi seleziona Gestione AD FS.
  2. Selezionare l'attendibilità della relying party creata in precedenza.
  3. Selezionare Proprietà, quindi selezionare Avanzamento
  4. Configurare l'algoritmo hash sicuro e selezionare OK per salvare le modifiche.

La richiesta HTTP-Redirect non contiene il parametro obbligatorio 'Signature' per una richiesta firmata (AADB2C90168)

Opzione 1: Impostare ResponsesSigned su false in Azure AD B2C

È possibile disabilitare il requisito del messaggio firmato in Azure AD B2C. L'esempio seguente configura Azure AD B2C per non richiedere il parametro 'Signature' per la richiesta firmata.

<Metadata>
  <Item Key="WantsEncryptedAssertions">false</Item>
  <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Opzione 2: Impostare la relying party in AD FS per firmare sia Message che Assertion

In alternativa, è possibile configurare la relying party in AD FS come indicato di seguito:

  1. Aprire PowerShell come Amministrazione istrator ed eseguire Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion il cmdlet per firmare sia Message che Assertion.
  2. Eseguire Set-AdfsRelyingPartyTrust -TargetName <RP Name> e verificare che la proprietà SamlResponseSignature sia impostata su MessageAndAssertion.