Opzioni per la registrazione di un'applicazione SAML in Azure AD B2C

  • Articolo

Questo articolo descrive le opzioni di configurazione disponibili quando si connette Azure Active Directory B2C (Azure AD B2C) all'applicazione Security Assertion Markup Language (SAML).

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.

Specificare una firma di risposta SAML

È possibile specificare un certificato da usare per firmare i messaggi SAML. Il messaggio è l'elemento <samlp:Response> all'interno della risposta SAML inviata all'applicazione.

Se non si ha già una chiave dei criteri, crearne una. Configurare quindi l'elemento SamlMessageSigning dei metadati nel profilo tecnico dell'autorità di certificazione token SAML. StorageReferenceId deve fare riferimento al nome della chiave del criterio.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Algoritmo di firma

È possibile configurare l'algoritmo di firma usato per firmare l'asserzione SAML. I possibili valori sono Sha256, Sha384, Sha512 o Sha1. Assicurarsi che il profilo tecnico e l'applicazione usino lo stesso algoritmo di firma. Usare solo l'algoritmo supportato dal certificato.

Configurare l'algoritmo di firma usando la XmlSignatureAlgorithm chiave di metadati all'interno dell'elemento relying party Metadata .

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="XmlSignatureAlgorithm">Sha256</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Controllare la firma dell'asserzione SAML

Quando l'applicazione prevede che la sezione asserzione SAML sia firmata, assicurarsi che il provider di servizi SAML imposti su WantAssertionsSignedtrue. Se è impostato su false o non esiste, la sezione di asserzione non verrà firmata.

L'esempio seguente mostra i metadati per un provider di servizi SAML, con WantAssertionsSigned impostato su true.

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  </SPSSODescriptor>
</EntityDescriptor>

Certificato di firma

I criteri devono specificare un certificato da usare per firmare la sezione asserzioni SAML della risposta SAML. Se non si ha già una chiave dei criteri, crearne una. Configurare quindi l'elemento SamlAssertionSigning dei metadati nel profilo tecnico dell'autorità di certificazione token SAML. StorageReferenceId deve fare riferimento al nome della chiave del criterio.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Abilitare la crittografia nelle asserzioni SAML

Quando l'applicazione prevede che le asserzioni SAML siano in formato crittografato, assicurarsi che la crittografia sia abilitata nei criteri di Azure AD B2C.

Azure AD B2C usa il certificato di chiave pubblica del provider di servizi per crittografare l'asserzione SAML. La chiave pubblica deve esistere nell'endpoint dei metadati dell'applicazione SAML con il KeyDescriptoruse valore impostato su Encryption, come illustrato nell'esempio seguente:

<KeyDescriptor use="encryption">
  <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
    <X509Data>
      <X509Certificate>valid certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
</KeyDescriptor>

Per consentire ad Azure AD B2C di inviare asserzioni crittografate, impostare l'elemento WantsEncryptedAssertion dei metadati su true nel profilo tecnico della relying party. È anche possibile configurare l'algoritmo usato per crittografare l'asserzione SAML.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Metodo di crittografia

Per configurare il metodo di crittografia usato per crittografare i dati dell'asserzione SAML, impostare la DataEncryptionMethod chiave di metadati all'interno della relying party. I valori possibili sono Aes256 (impostazione predefinita), Aes192, Sha512o Aes128. I metadati controllano il valore dell'elemento <EncryptedData> nella risposta SAML.

Per configurare il metodo di crittografia per crittografare la copia della chiave usata per crittografare i dati dell'asserzione SAML, impostare la KeyEncryptionMethod chiave di metadati all'interno della relying party. I valori possibili sono:

  • Rsa15 (impostazione predefinita): algoritmo RSA Public Key Cryptography Standard (PKCS) versione 1.5.
  • RsaOaep: algoritmo di crittografia OAEP (Optimal Asymmetric Encryption Padding) RSA.

I metadati controllano il valore dell'elemento <EncryptedKey> nella risposta SAML.

Nell'esempio seguente viene illustrata la EncryptedAssertion sezione di un'asserzione SAML. Il metodo di dati crittografato è Aes128e il metodo della chiave crittografata è Rsa15.

<saml:EncryptedAssertion>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <dsig:KeyInfo>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAssertion>

È possibile modificare il formato delle asserzioni crittografate. Per configurare il formato di crittografia, impostare la UseDetachedKeys chiave di metadati all'interno della relying party. Valori possibili: true o false (impostazione predefinita). Quando il valore è impostato su true, le chiavi scollegate aggiungono l'asserzione crittografata come figlio di EncryptedDataEncryptedAssertion anziché .

Configurare il metodo di crittografia e il formato usando le chiavi di metadati all'interno del profilo tecnico della relying party:

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="DataEncryptionMethod">Aes128</Item>
      <Item Key="KeyEncryptionMethod">Rsa15</Item>
      <Item Key="UseDetachedKeys">false</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Configurare il flusso avviato da IdP

Quando l'applicazione prevede di ricevere un'asserzione SAML senza prima inviare una richiesta SAML AuthN al provider di identità (IdP), è necessario configurare Azure AD B2C per il flusso avviato da IdP.

Nel flusso avviato da IdP il provider di identità (Azure AD B2C) avvia il processo di accesso. Il provider di identità invia una risposta SAML non richiesta al provider di servizi (applicazione relying party).

Attualmente non sono supportati scenari in cui il provider di identità di avvio è un provider di identità esterno federato con Azure AD B2C, ad esempio Active Directory Federation Services o Salesforce. Il flusso avviato da IdP è supportato solo per l'autenticazione dell'account locale in Azure AD B2C.

Per abilitare il flusso avviato da IdP, impostare l'elemento dei IdpInitiatedProfileEnabled metadati su true nel profilo tecnico della relying party.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="IdpInitiatedProfileEnabled">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

Per accedere o iscriversi a un utente tramite il flusso avviato da IdP, usare l'URL seguente:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state>

Sostituire i valori seguenti:

  • Sostituire <tenant-name> con il nome del tenant.
  • Sostituire <policy-name> con il nome dei criteri della relying party SAML.
  • Sostituire <app-identifier-uri> con il identifierUris valore nel file di metadati, ad esempio https://contoso.onmicrosoft.com/app-name.
  • [Facoltativo] sostituire <relay-state> con un valore incluso nella richiesta di autorizzazione restituito anche nella risposta del token. Il relay-state parametro viene usato per codificare informazioni sullo stato dell'utente nell'app prima che si sia verificata la richiesta di autenticazione, ad esempio la pagina in cui si trovavano.

Criterio di esempio

È possibile usare un criterio di esempio completo per i test con l'app di test SAML:

  1. Scaricare i criteri di esempio di accesso avviati da SAML-SP.
  2. Aggiornare TenantId in modo che corrisponda al nome del tenant. Questo articolo usa l'esempio contoso.b2clogin.com.
  3. Mantenere il nome del criterio B2C_1A_signup_signin_saml.

Configurare la durata della risposta SAML

È possibile configurare l'intervallo di tempo in cui la risposta SAML rimane valida. Impostare la durata usando l'elemento TokenLifeTimeInSeconds di metadati all'interno del profilo tecnico dell'autorità di certificazione del token SAML. Questo valore è il numero di secondi che possono trascorrere dal NotBefore timestamp, calcolato al momento del rilascio del token. La durata predefinita è 300 secondi (cinque minuti).

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenLifeTimeInSeconds">400</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Configurare l'asimmetria temporale di una risposta SAML

È possibile configurare l'asimmetria temporale applicata al timestamp di risposta NotBefore SAML. Questa configurazione garantisce che se i tempi tra due piattaforme non sono sincronizzati, l'asserzione SAML verrà comunque considerata valida quando è entro questo intervallo di tempo.

Impostare l'asimmetria temporale usando l'elemento TokenNotBeforeSkewInSeconds dei metadati all'interno del profilo tecnico dell'autorità di certificazione del token SAML. Il valore di asimmetria viene specificato in secondi, con un valore predefinito pari a 0. Il valore massimo è 3600 (un'ora).

Ad esempio, quando TokenNotBeforeSkewInSeconds è impostato su 120 secondi:

  • Il token viene emesso alle 13:05:10 UTC.
  • Il token è valido dalle 13:03:10 UTC.
<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Rimuovere millisecondi dalla data e dall'ora

È possibile specificare se i millisecondi verranno rimossi dai valori di data e ora all'interno della risposta SAML. Questi valori includono IssueInstant, NotBefore, NotOnOrAftere AuthnInstant. Per rimuovere i millisecondi, impostare la RemoveMillisecondsFromDateTime chiave di metadati all'interno della relying party. Valori possibili: false (impostazione predefinita) o true.

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
        <Item Key="RemoveMillisecondsFromDateTime">true</Item>
      </Metadata>
      <OutputClaims>
             ...
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
    </TechnicalProfile>
  </RelyingParty>

Usare un ID autorità di certificazione per eseguire l'override di un URI dell'autorità di certificazione

Se sono presenti più applicazioni SAML che dipendono da valori diversi entityID , è possibile eseguire l'override del IssuerUri valore nel file della relying party. Per eseguire l'override dell'URI dell'autorità di certificazione, copiare il profilo tecnico con l'ID dal file di base ed eseguire l'override Saml2AssertionIssuer del IssuerUri valore.

Suggerimento

Copiare la <ClaimsProviders> sezione dalla base e mantenere questi elementi all'interno del provider di attestazioni: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer">e <DisplayName>Token Issuer</DisplayName>.

Esempio:

   <ClaimsProviders>   
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Saml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Metadata>
            <Item Key="IssuerUri">customURI</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
  </ClaimsProviders>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpInSAML" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
     …

Gestire una sessione

È possibile gestire la sessione tra Azure AD B2C e l'applicazione relying party SAML usando l'elemento UseTechnicalProfileForSessionManagement e SamlSSOSessionProvider.

Forzare gli utenti a ripetere l'autenticazione

Per forzare gli utenti a ripetere l'autenticazione, l'applicazione può includere l'attributo ForceAuthn nella richiesta di autenticazione SAML. L'attributo ForceAuthn è un valore booleano. Quando è impostata su true, la sessione dell'utente verrà invalidata in Azure AD B2C e l'utente è costretto a ripetere l'autenticazione.

La richiesta di autenticazione SAML seguente illustra come impostare l'attributo ForceAuthn su true.

<samlp:AuthnRequest 
       Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
       ForceAuthn="true" ...>
    ...
</samlp:AuthnRequest>

Firmare i metadati SAML idP di Azure AD B2C

È possibile indicare ad Azure AD B2C di firmare il relativo documento di metadati per il provider di identità SAML, se l'applicazione lo richiede. Se non si ha già una chiave dei criteri, crearne una. Configurare quindi l'elemento MetadataSigning dei metadati nel profilo tecnico dell'autorità di certificazione token SAML. StorageReferenceId deve fare riferimento al nome della chiave del criterio.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

Eseguire il debug del protocollo SAML

Per configurare ed eseguire il debug dell'integrazione con il provider di servizi, è possibile usare un'estensione del browser per il protocollo SAML. Le estensioni del browser includono l'estensione SAML DevTools per Chrome, SAML-tracer per Firefox e Strumenti di sviluppo per Edge o Internet Explorer.

Usando questi strumenti, è possibile controllare l'integrazione tra l'applicazione e Azure AD B2C. Ad esempio:

  • Controllare se la richiesta SAML contiene una firma e determinare quale algoritmo viene usato per accedere alla richiesta di autorizzazione.
  • Controllare se Azure AD B2C restituisce un messaggio di errore.
  • Controllare se la sezione asserzione è crittografata.

Passaggi successivi

  • Per altre informazioni sul protocollo SAML, vedere il sito Web OASIS.
  • Ottenere l'app Web di test SAML dal repository della community GitHub di Azure AD B2C.