Configuración de las opciones del proveedor de identidades de SAML con Azure Active Directory B2C

Artículo
03/23/2023

Azure Active Directory B2C (Azure AD B2C) admite la Federación con proveedores de identidades de SAML 2.0. En este artículo se describen cómo analizar las aserciones de seguridad y las opciones de configuración que están disponibles al habilitar el inicio de sesión con un proveedor de identidades 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.

Asignación de notificaciones

El elemento OutputClaims contiene una lista de notificaciones devueltas por el proveedor de identidades de SAML. Debe asignar el nombre de la notificación definida en la directiva al nombre definido en el proveedor de identidades. Consulte el proveedor de identidades para obtener la lista de notificaciones (aserciones). También puede comprobar el contenido de la respuesta de SAML que devuelve el proveedor de identidades. Para obtener más información, consulte depurar los mensajes SAML. Para agregar una notificación, primero defina una notificación y, después, agregue la notificación a la colección de notificaciones de entrada.

También puede incluir notificaciones no especificadas por el proveedor de identidades, siempre que establezca el atributo DefaultValue. El valor predeterminado puede ser estático o dinámico, mediante notificaciones de contexto.

El elemento de notificación de entrada contiene los atributos siguientes:

ClaimTypeReferenceId es la referencia a un tipo de notificación.
PartnerClaimType es el nombre de la propiedad que aparece en la instrucción de aserción SAML.
DefaultValue es un valor predeterminado predefinido. Si la notificación está vacía, se usa el valor predeterminado. También puede utilizar resoluciones de notificaciones con un valor contextual, como el id. de correlación o la dirección IP del usuario.

Nombre de sujeto

Para leer la aserción SAML NamedId en Subject como si fuera una notificación normalizada, establezca la notificación PartnerClaimType en el valor del atributo SPNameQualifier. Si el atributo SPNameQualifier no aparece, establezca la notificación PartnerClaimType en el valor del atributo NameQualifier.

Aserción SAML:

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

Notificación de salida:

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

Si los atributos SPNameQualifier o NameQualifier no se encuentran en la aserción SAML, establezca la notificación PartnerClaimType en assertionSubjectName. Asegúrese de que NameId es el primer valor en el XML de la aserción. Cuando defina más de una aserción, Azure AD B2C toma el valor del tema de la última aserción.

Configurar enlaces de protocolo SAML

Las solicitudes SAML se envían al proveedor de identidades tal y como se especifica en el elemento de metadatos del proveedor de identidades SingleSignOnService. La mayoría de las solicitudes de autorización de los proveedores de identidades se transfieren directamente en la cadena de consulta de la dirección URL de una solicitud HTTP GET (dado que los mensajes son relativamente cortos). Consulte la documentación del proveedor de identidades para obtener información sobre cómo configurar los enlaces para ambas solicitudes SAML.

A continuación se proporciona un ejemplo XML de un servicio de inicio de sesión único de metadatos de Microsoft Entra con dos enlaces. HTTP-Redirect tiene prioridad sobre HTTP-POST porque aparece en primer lugar en los metadatos del proveedor de identidades de SAML.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

Servicio de consumidor de aserciones

El Servicio de consumidor de aserciones (o ACS) es el lugar donde Azure AD B2C envía y recibe las respuestas SAML del proveedor de identidades. Las respuestas SAML se transmiten a Azure AD B2C a través del enlace HTTP POST. La ubicación de ACS apunta a la directiva base del usuario de confianza. Por ejemplo, si la directiva de confianza es B2C_1A_signup_signin, ACS es la directiva base de B2C_1A_signup_signin, como B2C_1A_TrustFrameworkBase.

El siguiente es un ejemplo XML de un elemento de servicio del consumidor de aserción de metadatos de la directiva de Azure AD B2C.

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

Configurar la firma de la solicitud SAML

Azure AD B2C firma todas las solicitudes de autenticación salientes mediante la clave criptográfica SamlMessageSigning. Para deshabilitar la firma de la solicitud SAML, establezca WantsSignedRequests en false. Si los metadatos se establecen en false, se omiten los parámetros SigAlg y Signature (cadena de consulta o parámetro posterior) de la solicitud.

Estos metadatos también controlan el atributo AuthnRequestsSigned, que se incluye en los metadatos del perfil técnico de Azure AD B2C que se comparte con el proveedor de identidades. Azure AD B2C no firma la solicitud si el valor de WantsSignedRequests en los metadatos del perfil técnico se establece en false y los metadatos del proveedor de identidades WantAuthnRequestsSigned están establecidos en false o no se han especificado.

En el siguiente ejemplo se quita la firma del certificado de la solicitud SAML.

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

Algoritmo de firma

Azure AD B2C usa Sha1 para firmar la solicitud SAML. Use los metadatos de XmlSignatureAlgorithm para configurar el algoritmo que se va a usar. Los valores posibles son Sha256, Sha384, Sha512 o Sha1 (valor predeterminado). Estos metadatos controlan el valor del parámetro SigAlg (cadena de consulta o parámetro post) en la solicitud SAML. Asegúrese de configurar el algoritmo de firma en ambos lados con el mismo valor. Use solo el algoritmo que admite el certificado.

Incluir información de clave

Cuando el proveedor de identidades indica que Azure AD B2C enlace está establecido en HTTP-POST, Azure AD B2C incluye la firma y el algoritmo en el cuerpo de la solicitud SAML. También puede configurar Microsoft Entra ID para incluir la clave pública del certificado cuando el enlace se establece en HTTP-POST. Use los metadatos de IncludeKeyInfo para true o false. En el ejemplo siguiente, Microsoft Entra ID no incluye la clave pública del certificado.

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

Configurar el identificador de nombre de la solicitud SAML

El elemento de solicitud de autorización de SAML <NameID> indica el formato del identificador de nombre de SAML. En esta sección se describe la configuración predeterminada y cómo personalizar el elemento de identificador de nombre.

Nombre de usuario preferido

Durante el recorrido de inicio de sesión de un usuario, una aplicación de usuario de confianza puede tener como destino un usuario específico. Azure AD B2C permite enviar un nombre de usuario preferido al proveedor de identidades de SAML. El elemento InputClaims se usa para enviar un objeto NameId en el Asunto de la solicitud de autorización de SAML.

Para incluir el identificador de nombre de sujeto dentro de la solicitud de autorización, agregue el siguiente <InputClaims> elemento inmediatamente después de <CryptographicKeys>. PartnerClaimType debe establecerse en subject.

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

En este ejemplo, Azure AD B2C envía el valor de la notificación signInName con NameId en el asunto de la solicitud de autorización de SAML.

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

Puede usar notificaciones de contexto, como {OIDC:LoginHint} para rellenar el valor de notificación.

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

Formato de la directiva de ID. de nombre

De forma predeterminada, la solicitud de autorización de SAML especifica la directiva urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. Este id. de nombre indica que se puede usar cualquier tipo de identificador compatible con el proveedor de identidades para el tema solicitado.

Para cambiar este comportamiento, consulte la documentación de su proveedor de identidades para obtener instrucciones sobre qué directivas de id. de nombre se admiten. A continuación, agregue los metadatos NameIdPolicyFormat en el formato de directiva correspondiente. Por ejemplo:

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

La siguiente solicitud de autorización de SAML contiene la directiva de ID. de nombre.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

Permitir la creación de cuentas nuevas

Si especifica el formato de directiva de identificador de nombre, también puede especificar la propiedad AllowCreate de NameIDPolicy para indicar si se permite al proveedor de identidades crear una nueva cuenta durante el flujo de inicio de sesión. Consulte la documentación del proveedor de identidades para obtener instrucciones.

Azure AD B2C omite la propiedad AllowCreate de forma predeterminada. Puede cambiar este comportamiento con los metadatos NameIdPolicyAllowCreate. El valor de estos metadatos es true o false.

En el ejemplo siguiente se muestra cómo establecer la propiedad AllowCreate de NameIDPolicy a true.

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

En el ejemplo siguiente se muestra una solicitud de autorización con AllowCreate del elemento NameIDPolicy en la solicitud de autorización.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

Forzado de la autenticación

Puede forzar que el IDP de SAML externo solicite al usuario que se autentique pasando la propiedad ForceAuthN en la solicitud de autenticación de SAML. Su proveedor de identidades también debe admitir esta propiedad.

La propiedad ForceAuthN es un valor booleano true o false. De manera predeterminada, Azure AD B2C establece el valor de ForceAuthN en false. Si después se restablece la sesión (por ejemplo, mediante el objeto prompt=login de OIDC), el valor de ForceAuthN se establece en true. Si se establece el elemento de metadatos ForceAuthN en true, se impone el valor al IDP externo para todas las solicitudes.

En el siguiente ejemplo se muestra la propiedad ForceAuthN establecida en true:

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

En el siguiente ejemplo se muestra la propiedad ForceAuthN en una solicitud de autorización:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

Nombre del proveedor

Opcionalmente, puede incluir el atributo ProviderName en la solicitud de autorización de SAML. Establezca el elemento de metadatos ProviderName para incluir el nombre del proveedor de todas las solicitudes al IDP de SAML externo. En el siguiente ejemplo se muestra la propiedad ProviderName establecida en Contoso app:

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

En el siguiente ejemplo se muestra la propiedad ProviderName en una solicitud de autorización:

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

Incluir referencias de clase de contexto de autenticación

Una solicitud de autorización de SAML puede contener un elemento AuthnContext, que especifica el contexto de una solicitud de autorización. El elemento puede contener una referencia de clase de contexto de autenticación, que indica al proveedor de identidades de SAML qué mecanismo de autenticación debe presentar al usuario.

Para configurar las referencias a la clase de contexto de autenticación, agregue metadatos de IncludeAuthnContextClassReferences. En el valor, especifica una o varias referencias de URI que identifican las clases de contexto de autenticación. Especifique varios URI como una lista delimitada por comas. Consulte la documentación del proveedor de identidades para obtener instrucciones sobre las URI de AuthnContextClassRef que se admiten.

En el ejemplo siguiente se permite a los usuarios iniciar sesión con el nombre de usuario y la contraseña, y para iniciar sesión con el nombre de usuario y la contraseña en una sesión protegida (SSL/TLS).

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

La siguiente solicitud de autorización de SAML contiene las referencias de la clase de contexto de autenticación.

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Incluir datos personalizados en la solicitud de autorización

Opcionalmente, puede incluir elementos de extensión de mensajes de protocolo acordados por Azure AD B2C y el proveedor de identidades. La extensión se presenta en formato XML. Los elementos de extensión se incluyen agregando datos XML dentro del elemento CDATA <![CDATA[Your Custom XML]]>. Consulte la documentación del proveedor de identidades para ver si se admite el elemento de extensiones.

En el siguiente ejemplo se muestra el uso de los datos de extensión:

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

Nota:

De acuerdo con la especificación SAML, los datos de extensión deben ser un XML de espacio de nombres (por ejemplo, "urn:ext:custom" que se muestra en el ejemplo) y no uno de los espacios de nombres específicos de SAML.

Al usar la extensión de mensaje de protocolo SAML, la respuesta SAML es similar al ejemplo siguiente:

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

Requerir respuestas SAML firmadas

Azure AD B2C requiere que se firmen todas las aserciones entrantes. Puede quitar este requisito estableciendo WantsSignedAssertions en false. En este caso no es necesario que el proveedor de identidades firme las aserciones, pero aunque lo haga, Azure AD B2C no validará la firma.

Los metadatos WantsSignedAssertions controlan la marca de metadatos WantAssertionsSigned, que se incluye en los metadatos del perfil técnico de Azure AD B2C que se comparte con el proveedor de identidades.

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Si deshabilita la validación de las aserciones, también puede interesarle deshabilitar la validación de la firma de respuesta. Establecer los metadatos ResponsesSigned en false. En este caso no es necesario que el proveedor de identidades firme el mensaje de la respuesta SAML, pero incluso si lo hace, Azure AD B2C no validará la firma.

En el ejemplo siguiente se quitan tanto el mensaje como la firma de aserción:

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Requerir respuestas SAML cifradas

Para requerir el cifrado de todas las aserciones entrantes, establezca los metadatos de WantsEncryptedAssertions. Cuando se requiere cifrado, el proveedor de identidades usa una clave pública de un certificado de cifrado en un perfil técnico de Azure AD B2C. Azure AD B2C descifra la aserción de respuesta mediante la parte privada del certificado de cifrado.

Si habilita el cifrado de aserciones, es posible que también tenga que deshabilitar la validación de firma de respuesta (para obtener más información, consulte Solicitar respuestas SAML firmadas).

Cuando los metadatos WantsEncryptedAssertions se establecen en true, los metadatos del perfil técnico de Azure AD B2C incluyen la sección cifrado. El proveedor de identidades lee los metadatos y cifra la aserción de respuesta de SAML con la clave pública que se proporciona en los metadatos del perfil técnico de Azure AD B2C.

En el ejemplo siguiente se muestra la sección del descriptor de clave de los metadatos de SAML usados para el cifrado:

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

Para cifrar la aserción de respuesta SAML:

Cree una clave de directiva con un identificador único. Por ejemplo, B2C_1A_SAMLEncryptionCert.
En la colección CryptographicKeys de perfil técnico de SAML. Asigne el nombre de la clave de directiva que creó en el primer paso a StorageReferenceId. El identificador SamlAssertionDecryption indica el uso de la clave criptográfica para cifrar y descifrar la aserción de la respuesta de SAML.
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```

Establezca los metadatos del perfil técnico WantsEncryptedAssertions en true.

<Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>

Actualice el proveedor de identidades con los nuevos metadatos del perfil técnico de Azure AD B2C. La propiedad use de KeyDescriptor debería estar establecida en encryption y contener la clave pública del certificado.

Habilitar el uso de notificaciones de contexto

En la colección de notificaciones de entrada y salida, puede incluir las notificaciones que el proveedor de identidades no devuelve, siempre y cuando establezca el atributo DefaultValue. También puede usar notificaciones de contexto para incluirlas en el perfil técnico. Para usar una demanda de contexto:

Agregue un tipo de demanda al elemento ClaimsSchema en BuildingBlocks.
Agregue una notificación de salida a la colección de entrada o de salida. En el ejemplo siguiente, la primera notificación establece el valor del proveedor de identidades. La segunda notificación usa las notificaciones de contexto de la dirección IP del usuario.
```
<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>
```

Deshabilitar cierre de sesión único

En una solicitud de cierre de sesión de aplicación, Azure AD B2C intenta cerrar la sesión del proveedor de identidades de SAML. Para más información, consulte Cierre de sesión de Azure AD B2C. Para deshabilitar el comportamiento de cierre de sesión único, establezca los metadatos SingleLogoutEnabled en false.

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

Depurar protocolo SAML

Para ayudar a configurar y depurar la federación con el proveedor de identidades SAML, puede usar una extensión del navegador para el protocolo SAML; como la extensión SAML DevTools para Chrome, SAML-Tracer para Firefox o las herramientas para desarrolladores de Microsoft Edge o IE.

Con estas herramientas, puede comprobar la integración entre Azure AD B2C y el proveedor de identidades de SAML. 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.
Obtiene las notificaciones (aserciones) en la sección AttributeStatement.
Compruebe si el proveedor de identidades devuelve un mensaje de error.
Compruebe si la sección de aserción está cifrada.

Ejemplos de solicitudes y respuestas SAML

El Lenguaje de marcado de aserción de seguridad (SAML) es un estándar abierto para intercambiar datos de autenticación y autorización entre un proveedor de identidades y un proveedor de servicios. Cuando Azure AD B2C se federa con un proveedor de identidades de SAML, actúa como proveedor de servicios. Para ello, inicia una solicitud SAML al proveedor de identidades de SAML y espera una respuesta SAML.

Una respuesta SAML correcta contiene aserciones de seguridad que son instrucciones realizadas por los proveedores de identidades SAML externos. Azure AD B2C analiza y asigna las aserciones a notificaciones.

Solicitud de autorización

Para solicitar una autenticación de usuario, Azure AD B2C envía un elemento AuthnRequest al proveedor de identidades SAML externo. Una muestra de SAML 2.0 AuthnRequest debería tener un aspecto similar al ejemplo siguiente:

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

Response

Cuando un inicio de sesión solicitado se completa correctamente, el proveedor de identidades SAML externo envía una respuesta al punto de conexión del servicio de consumidor de aserciones de Azure AD B2C. Una respuesta a un intento de inicio de sesión correcto tiene este aspecto:

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Solicitud de cierre de sesión

En una solicitud de cierre de sesión de aplicación, Azure AD B2C intenta cerrar la sesión del proveedor de identidades de SAML. Azure AD B2C envía un mensaje LogoutRequest al IDP externo para indicar que se ha terminado una sesión. El extracto siguiente muestra un ejemplo de elemento LogoutRequest .

El valor del elemento NameID coincide con el NameID del usuario que cierra la sesión. El elemento SessionIndex coincide con el atributo SessionIndex de AuthnStatement en la respuesta SAML de inicio de sesión.

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

Pasos siguientes

Obtenga información sobre cómo diagnosticar problemas con las directivas personalizadas mediante Application Insights.

Compartir vía