Opciones para registrar una aplicación SAML en Azure AD B2C

En este artículo se describen las opciones de configuración que están disponibles al conectar Azure Active Directory B2C (Azure AD B2C) con la aplicación de Lenguaje de marcado de aserción de seguridad (SAML).

Antes de comenzar, use el selector Elección de un tipo de directiva para elegir el tipo de directiva que va a configurar. Azure Active Directory B2C ofrece dos métodos para definir el modo en que los usuarios interactúan con las aplicaciones: por medio de flujos de usuario predefinidos o de directivas personalizadas totalmente configurables. Los pasos necesarios en este artículo son diferentes para cada método.

Esta característica está disponible solo para directivas personalizadas. En los pasos de configuración, elija Directiva personalizada en el selector anterior.

Especificación de una firma de respuesta de SAML

Puede especificar un certificado que se utilizará para firmar los mensajes SAML. El mensaje es el elemento <samlp:Response> dentro de la respuesta SAML enviada a la aplicación.

Si aún no tiene una clave de directiva, créela. A continuación, configure el elemento de metadatos SamlMessageSigning en el perfil técnico del emisor de tokens de SAML. StorageReferenceId debe hacer referencia al nombre de la clave de la directiva.

<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 de firma

Puede configurar el algoritmo de firma utilizado para firmar la aserción SAML. Los valores posibles son Sha256, Sha384, Sha512 o Sha1. Asegúrese de que el perfil técnico y la aplicación usan el mismo algoritmo de firma. Use solo el algoritmo que admite el certificado.

Configure el algoritmo de firma mediante la clave de metadatos XmlSignatureAlgorithm en el elemento Metadata del usuario de confianza.

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

Comprobación de la firma de aserción SAML

Cuando una aplicación espere que se firme la sección de aserciones de SAML, asegúrese de que el proveedor de servicios de SAML haya establecido WantAssertionsSigned en true. Si lo ha establecido en false o no existe, la sección de aserciones no se firmará.

En el ejemplo siguiente se muestran los metadatos del proveedor de servicios de SAML con WantAssertionsSigned establecido en 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>

Certificado de firma

La directiva debe especificar que se use un certificado para firmar la sección de aserciones de SAML de la respuesta de SAML. Si aún no tiene una clave de directiva, créela. A continuación, configure el elemento de metadatos SamlAssertionSigning en el perfil técnico del emisor de tokens de SAML. StorageReferenceId debe hacer referencia al nombre de la clave de la directiva.

<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>

Habilitación del cifrado en aserciones SAML

Si la aplicación espera que las aserciones SAML estén en un formato cifrado, debe asegurarse de que el cifrado esté habilitado en la directiva de Azure AD B2C.

Azure AD B2C utiliza el certificado de clave pública del proveedor de servicios para cifrar la aserción SAML. La clave pública debe existir en el punto de conexión de metadatos de la aplicación SAML con el valor KeyDescriptoruse establecido en Encryption, como se muestra en el ejemplo siguiente:

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

Para habilitar Azure AD B2C para enviar aserciones cifradas, establezca el elemento de metadatos WantsEncryptedAssertion en true en el perfil técnico del usuario de confianza. También puede configurar el algoritmo utilizado para cifrar la aserción SAML.

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

Encryption method

Para configurar el método de cifrado que se usa para cifrar los datos de aserción SAML, establezca la clave de metadatos DataEncryptionMethod en el usuario de confianza. Los valores posibles son: Aes256 (predeterminado), Aes192, Sha512 o Aes128. Los metadatos controlan el valor del elemento <EncryptedData> en la respuesta de SAML.

Para configurar el método de cifrado que se usa para cifrar la copia de la clave que se usó para cifrar los datos de aserción SAML, establezca la clave de metadatos KeyEncryptionMethod en el usuario de confianza. Los valores posibles son:

• Rsa15 (valor predeterminado): algoritmo Public Key Cryptography Standard (PKCS) de RSA, versión 1.5.
• RsaOaep: algoritmo de cifrado Optimal Asymmetric Encryption Padding (OAEP) de RSA.

Los metadatos controlan el valor del elemento <EncryptedKey> en la respuesta de SAML.

En el ejemplo siguiente se muestra la sección EncryptedAssertion de una aserción SAML. El método de cifrado de datos es Aes128 y el método de cifrado de clave es 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>

Puede cambiar el formato de las aserciones cifradas. Para configurar el formato de cifrado, establezca la clave de metadatos UseDetachedKeys en el usuario de confianza. Valores posibles: true o false (valor predeterminado). Cuando el valor se establece en true, las claves desasociadas agregan la aserción cifrada como elemento secundario de EncryptedAssertion y no de EncryptedData.

Para configurar el método y el formato de cifrado, use las claves de metadatos del perfil técnico del usuario de confianza:

<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>

Configuración del flujo iniciado por IdP

Si la aplicación espera recibir una aserción SAML sin enviar primero una solicitud de autenticación SAML al proveedor de identidades (IdP), debe configurar Azure AD B2C para el flujo iniciado por IdP.

En el flujo iniciado por IdP, el proveedor de identidades (Azure AD B2C) comienza el proceso de inicio de sesión. El proveedor de identidades envía una respuesta SAML no solicitada al proveedor de servicios (la aplicación de usuario de confianza).

Actualmente no se admiten escenarios en los que el proveedor de identidades que inicia el proceso sea un proveedor de identidades externo federado con Azure AD B2C; por ejemplo Servicios de federación de Active Directory (AD FS) o Salesforce. El flujo iniciado por IdP solo se admite para la autenticación de cuentas locales en Azure AD B2C.

Para habilitar el flujo iniciado por IdP, establezca el elemento de metadatos IdpInitiatedProfileEnabledIen true en el perfil técnico del usuario de confianza.

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

Para iniciar sesión o registrar un usuario mediante el flujo iniciado por IdP, use la siguiente dirección URL:

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

Reemplace los siguientes valores:

• Remplace <tenant-name> por el nombre del inquilino.
• Reemplace <policy-name> por el nombre de la directiva de usuario de confianza de SAML.
• Reemplace <app-identifier-uri> por el valor identifierUris del archivo de metadatos, por ejemplo, https://contoso.onmicrosoft.com/app-name.
• [Opcional] Reemplace <relay-state> por un valor incluido en la solicitud de autorización que también se devuelve en la respuesta del token. El parámetro relay-state también se usa para codificar información sobre el estado del usuario en la aplicación antes de que se haya producido la solicitud de autenticación, por ejemplo, la página en la que estaban.

Directiva de ejemplo

Puede usar una directiva de ejemplo completa para realizar pruebas con la aplicación de prueba de SAML:

1. Descargue la directiva de ejemplo de inicio de sesión iniciada por el proveedor de servicios SAML.
2. Actualice TenantId para que coincida con su nombre de inquilino. En este artículo se usa el ejemplo contoso.b2clogin.com.
3. Mantenga el nombre de la directiva B2C_1A_signup_signin_saml.

Configuración de la duración de respuesta de SAML

Puede configurar el período de tiempo durante el que la respuesta de SAML sigue siendo válida. Establezca la duración mediante el elemento de metadatos TokenLifeTimeInSeconds en el perfil técnico del emisor de tokens de SAML. Este valor es el número de segundos que pueden transcurrir desde la marca de tiempo NotBefore calculada en el momento de emitir el token. La duración predeterminada es de 300 segundos (5 minutos).

<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>

Configuración del desfase horario de una respuesta de SAML

Puede configurar el desfase horario que se aplica a la marca de tiempo NotBefore de la respuesta de SAML. Esta configuración garantiza que, si las horas entre dos plataformas no están sincronizadas, la aserción SAML seguirá considerándose válida cuando se encuentre dentro de este desfase horario.

Establezca el desfase horario mediante el elemento de metadatos TokenNotBeforeSkewInSeconds en el perfil técnico del emisor de tokens de SAML. El valor de desfase se proporciona en segundos, con un valor predeterminado de 0. El valor máximo es 3600 (una hora).

Por ejemplo, si TokenNotBeforeSkewInSeconds está establecido en 120 segundos:

• El token se emite a las 13:05:10 UTC.
• El token es válido a partir de las 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>

Eliminación de milisegundos de la fecha y hora

Puede especificar si se eliminarán milisegundos de los valores de fecha y hora en la respuesta SAML. (Estos valores incluyen IssueInstant, NotBefore, NotOnOrAfter y AuthnInstant). Para quitar los milisegundos, establezca la clave de metadatos RemoveMillisecondsFromDateTime en el usuario de confianza. Valores posibles: false (predeterminado) 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>

Uso de un identificador de emisor para invalidar un URI del emisor

Si tiene varias aplicaciones SAML que dependen de distintos valores de entityID, puede reemplazar el valor de IssuerUri del archivo de usuario de confianza. Para reemplazar el URI del emisor, copie el perfil técnico con el identificador IssuerUri del archivo base y reemplace el valor Saml2AssertionIssuer.

Sugerencia

Copie la sección <ClaimsProviders> de la base y conserve estos elementos en el proveedor de notificaciones: <DisplayName>Token Issuer</DisplayName>, <TechnicalProfile Id="Saml2AssertionIssuer"> y <DisplayName>Token Issuer</DisplayName>.

Ejemplo:

   <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>
     …

Administrar una sesión

Puede administrar la sesión entre Azure AD B2C y la aplicación de usuario de confianza SAML mediante los elementos UseTechnicalProfileForSessionManagement y SamlSSOSessionProvider.

Obligatoriedad de que los usuarios vuelvan a autenticarse

Para obligar a los usuarios a volver a autenticarse, la aplicación puede incluir el atributo ForceAuthn en la solicitud de autenticación de SAML. El atributo ForceAuthn es un valor booleano. Cuando se establece en true, la sesión del usuario se invalidará en Azure AD B2C y el usuario tendrá que volver a autenticarse.

La siguiente solicitud de autenticación de SAML muestra cómo establecer el atributo ForceAuthn en true.

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

Firma de los metadatos de SAML del IdP de Azure AD B2C

Puede indicar a Azure AD B2C que firme su documento de metadatos del proveedor de identidades de SAML, si la aplicación así lo requiere. Si aún no tiene una clave de directiva, créela. A continuación, configure el elemento de metadatos MetadataSigning en el perfil técnico del emisor de tokens de SAML. StorageReferenceId debe hacer referencia al nombre de la clave de la directiva.

<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>

Depuración del protocolo SAML

Para ayudar a configurar y depurar la integración con el proveedor de servicios, puede usar una extensión de navegador para el protocolo SAML. Las extensiones de explorador incluyen la extensión SAML DevTools para Chrome, SAML-tracer para Firefox y Herramientas de desarrollo para Edge o Internet Explorer.

Con estas herramientas, puede comprobar la integración entre la aplicación y Azure AD B2C. Por ejemplo:

• Puede comprobar si la solicitud SAML contiene una firma y determinar qué algoritmo se usa para iniciar sesión en la solicitud de autorización.
• Puede comprobar si Azure AD B2C devuelve un mensaje de error.
• Compruebe si la sección de aserción está cifrada.

Pasos siguientes

• Puede encontrar más información sobre el protocolo SAML en el sitio web de OASIS.
• Obtenga la aplicación web de prueba de SAML en el repositorio de Azure AD B2C de la comunidad de GitHub.