Tabla de contenido

 

SAML Visión general

• Componentes de SAML SSO la solución.

• Casos de uso.

• SAML Flujo lógico.

• TOOLS.

• SAML Mensajes.

• • SAML Solicitud de autenticación.

  • SAML Respuesta de autenticación.

  • SAML Solicitud de cierre de sesión.

  • SAML Respuesta de cierre de sesión.

• Metadatos idp XML .

• SP Metadatos XML .

 

 

 

SAML Visión general

 

El lenguaje de marcado de aserción de seguridad 2.0 (SAML 2.0) es un XML- estándar basado para intercambiar datos de autenticación y autorización entre dominios de seguridad. SAML resuelve principalmente dos requisitos en la empresa: inicio de sesión único basado en web en varias entidades e identidad federada. Single Sign-On se logra mediante el intercambio de información entre varias aplicaciones y organizaciones. Identidad federada permite un conjunto de prestadores de servicios para acordar una manera de referirse a un solo usuario, incluso si ese usuario es conocido por los proveedores en distintas formas.

 

Componentes de SAML SSO la solución

 

Normalmente, tres entidades participan en una SAML transacción:

• Principal (usuario)
• Proveedor de servicios ( SP )
• Proveedor de identidad (IdP)

 

El proveedor de servicios suele ser la aplicación o servicio que un director ha solicitado acceso a y el proveedor de identidad es la entidad que está enchufada en la identidad almacenar lleva las credenciales del usuario. SAML no define las técnicas que un IdP puede utilizar para autenticar al usuario - en su lugar, se centra en definir el intercambio de información entre a SP y un IdP para indicar el estado de autenticación y autorización de la entidad de seguridad. Esto da al IdP la libertad de utilizar técnicas de autenticación adicionales (2FA/, MFA autenticación basada en certificados...) para autenticar al usuario. SAML los mensajes se utilizan XML como formato de intercambio de datos y se transportan con un fuerte requisito para proteger estos mensajes mediante / HTTP ( SSL TLS HTTPS )

 

SAML La aserción contiene información sobre la autenticación y el usuario. La afirmación de que la información contenida, el receptor puede utilizar para tomar una decisión de control de acceso. Hay 3 tipos de declaraciones de afirmación:

 

• La instrucción authentication contiene información como el tiempo y el método utilizados para garantizar la identidad del usuario.

 

• Declaración de atributo contiene información sobre el usuario como nombre de usuario, número de teléfono, dirección ... etcetera.

 

• La instrucción de decisión de autorización confirma si el usuario está autorizado a acceder a un recurso especificado.

 

SAML usa tokens de seguridad que contienen aserciones para pasar información sobre una entidad de seguridad (normalmente un usuario final) entre una SAML autoridad, es decir, un proveedor de identidades y un SAML consumidor, es decir, un proveedor de servicios. Por ejemplo, el proveedor de identidad afirma que este usuario ha sido autenticado y ha dado atributos asociados. En SAML , los proveedores de identidad también se conocen como SAML autoridades y partes afirmantes. Los Proveedores de Servicios también se conocen como Partes De Confianza , debido al hecho de que "confían" en la información proporcionada por un Proveedor de Identidad (Asserting Party). El proveedor de identidades reenvía las aserciones al servicio de consumidor de aserción ( ) y este servicio ACS URL valida las aserciones para asegurarse de si el usuario final está autorizado a obtener acceso a la aplicación y otros recursos. ACS URL es importante porque es URL ahí donde el proveedor de servicios recibirá y consumirá las aserciones.

 

Los protocolos de comunicación o mensajería de nivel inferior (por ejemplo HTTP o ) sobre los que se pueden transportar los mensajes se definen mediante SOAP SAML enlaces. SAML Los enlaces son enlaces en un punto final que dictan cómo se comunica un SP & un IdP. Con HTTP como transporte, las fijaciones típicas incluyen REDIRECT ( HTTP 302) y POST ( HTTP POST ). HTTP Enlace de redirección:define cómo SAML se pueden transportar los mensajes de protocolo mediante mensajes de HTTP redirección (302 respuestas de código de estado).  SAML las solicitudes o respuestas transmitidas a través HTTP de Redirect tienen un parámetro de cadena de consulta SAMLRequest o SAMLResponse, respectivamente. Antes de enviarlo, el mensaje se desinfla (sin encabezado y suma de comprobación), codificado en base64 y URL- codificado, en ese orden. Una vez recibida, el proceso se invierte para recuperar el mensaje original. Tanto los SPs como los IDPs pueden transmitir y recibir mensajes mediante redirección o POST enlaces. Debido a la limitación de URL longitudes en ciertos escenarios, HTTP Redirección se utiliza generalmente al pasar mensajes cortos y HTTP POST se utiliza al pasar mensajes más largos.

 

HTTP POST Enlace: Define cómo SAML se pueden transportar los mensajes de protocolo dentro del contenido codificado en base64 de un HTML control de formulario.

Los puntos de conexión de Palo Alto Networks SP solo pueden aceptar mensajes cuando se SAML transportan mediante HTTP POST .

Otra SAML terminología a tener en cuenta son los metadatos. Lleva información de esquema y punto de conexión sobre el IdP y el SP archivo . Cada IdP y cada uno SP se espera que tengan sus propios metadatos. Los desplazados internos y SPs típicamente registro entre sí mediante metadatos. Normalmente, los metadatos contienen información como SSO URL el nombre del emisor y el certificado que contiene la clave PKI "pública". Por ejemplo, a SP puede usar esta información para confiar en una aserción procedente de un IdP y viceversa. SAML 2.0 proporciona un formato de metadatos bien definido e interoperable que las entidades pueden aprovechar para arrancar el proceso de confianza. Metadatos proporcionados por el IdP para SP contener información sobre IdP (como Entity ID , / SSO SLO URL ... etc) y viceversa.

 

 

Casos de uso

 

SSO para el Portal cautivo:

A los clientes les gustaría utilizar nuestra capacidad para lanzar un portal cautivo cuando un usuario intenta acceder a HTTP- recursos basados específicos. Para aliviar la necesidad de que un usuario inicie sesión varias veces, los clientes confían SAML- en ellos en función de SSO dónde, el usuario inicia sesión una vez con su IdP y, a continuación, se le permite el acceso a cualquier proveedor de servicios que esté registrado con el mismo IdP siempre y cuando el usuario pase las comprobaciones de autorización necesarias. Además, estos clientes también utilizan el portal cautivo para identificar de forma transparente a los usuarios (User- ID ), si la asignación /user del usuario ha IP caducado. Portal cautivo también puede utilizarse para autenticar un usuario conocido que está intentando acceder a un recurso protegido. Esta capacidad proporciona el nivel necesario de garantía de seguridad a los administradores y proporciona una interfaz simple, sin complicaciones para los usuarios finales. En una organización, varias aplicaciones pueden hacer uso los mismo desplazados para autenticar los usuarios. Siempre que las aplicaciones estén utilizando SAML y el mismo IdP para autenticar a los usuarios, el usuario obtiene una experiencia coherente cuando accede a esas aplicaciones y se autentica.

 

SSO para GlobalProtect :

A los clientes les gustaría usar SAML en función de . permite a estas empresas utilizar una única arquitectura para todas las SSO GlobalProtect SAML SSO aplicaciones, y para todos los usuarios en todas las plataformas de dispositivos. Puesto GlobalProtect que se ejecuta en varias plataformas, y ya que es SAML agnóstico de la plataforma, SAML es una opción perfecta para el inicio de sesión único. GP Las puertas de enlace y los portales actuarán como SAML proveedor de servicios, aplazando el proceso de aserción de identidad a un proveedor de SAML identidades de terceros.

 

SSO para Firewall / Panorama GUI :

Firewall y Panorama los administradores buscan acceder al administrador sin tener que iniciar sesión manualmente en GUI él. Permitir que los administradores autorizados accedan directamente a nuestro GUI dentro de una empresa que se ha implementado como estándar reduce el esfuerzo del usuario necesario para SAML iniciar SSO sesión, y permite que / firewall se base en un motor de autenticación Panorama centralizado para fines de aserción de identidad.

 

 

 

SAML Flujo lógico

 

En el siguiente ejemplo, podemos destacar el flujo de autenticación de un usuario mediante portal cautivo. Resalta la interacción entre el usuario, el recurso firewall (proveedor de servicios) y el IdP. El flujo de autenticación es similar para otros SP puntos de conexión (Admin, UI GlobalProtect Portal/Gateway, GlobalProtect SSL VPN Clientless)

 

 Flujo de autenticación

 

1. El usuario realiza una solicitud a un recurso (ya sea en un proveedor de servicios, como Firewall / o en otro servidor web , como Panorama GUI bing.com )
2. Si una solicitud a un recurso no es a Firewall / y si existe una regla de Panorama GUI Policy autenticación, se ejecuta y el usuario se redirige a un portal URL cautivo.
3. El navegador del usuario accede al Portal Cautivo URL
4. El proveedor de servicios crea un objeto AuthnRequest, que indica cómo SP se autentica el usuario. El AuthnRequest está codificado y se envía al proveedor de identidades a través HTTP POST o al método de HTTP redirección a través del navegador del usuario. Detalles sobre SAML AuthnRequest, Respuesta, etc... se explicará en la segunda mitad del documento.
5. Si desplazados anteriormente ha autenticado el usuario, el IdP envía una cookie que identifica el usuario. Esta cookie se almacena en el navegador. En continuación al paso anterior (paso 4), si el usuario se ha autenticado previamente con el PDI, junto con el AuthnRequest, cookie almacenado en el navegador también se envía a los desplazados a través del navegador del usuario. IdP comprueba si es una cookie válida. Si una cookie válida no existe, o si una cookie no existe, el IdP autentica al usuario. IdP presentará solicitud de inicio de sesión en el navegador y basado en el mecanismo de autenticación configurado, el usuario será autenticado. Por ejemplo, se podría configurar una autenticación basada en formulario simple y se puede consultar un LDAP servidor para realizar la búsqueda de usuarios. El usuario se presentará con una solicitud de inicio de sesión y en el navegador, el usuario introduce las credenciales de inicio de sesión y entradas a desplazados internos. El IdP envía las credenciales de inicio de sesión al LDAP servidor. LDAP el servidor comprueba las credenciales y devuelve el estado de validación al IdP.
6. El IdP crea una SAML aserción, la firma con su clave privada y redirige al usuario de nuevo al proveedor de servicios a través del HTTP POST método, incluida la SAML aserción. Utilizando la información proporcionada en la aserción, tomará SP las decisiones apropiadas, como proporcionar al usuario acceso al recurso protegido.
7. Proveedor de servicios valida la SAML aserción y XML firma proporcionada por el IdP. Extrae el nombre de usuario de la SAML aserción a través de los atributos username y verifica el usuario y el grupo de usuarios contra la lista allow. Si acceso a cheques pass, el recurso es entonces devuelto al explorador. El navegador completa la conexión a recursos como bing.com

 

TOOLS

 

Hay algunos DevTools que se pueden cargar en el navegador (como Chrome), que pueden ayudar en la depuración de SAML mensajes. Algunas de las extensiones de chrome popular son:

• SAML Chrome Panel
• SAML Extensión DevTools

 SAML Extensión DevTools

 

 

 

SAML Mensajes

 

SAML Solicitud de autenticación

 

AuthnRequest es un SAML mensaje que envía al SP IdP para iniciar la autenticación. Este mensaje es codificado en Base64 y se envía a la IdP. Junto con el Authnrequest codificado en Base64, SAML se envía un token relaystate al IdP. Relaystate token es un identificador opaco que hace referencia a la información de estado mantenida en el proveedor de servicios. Este símbolo se repite por el IdP en su mensaje de respuesta.

 

 

SAML AuthnRequest

Los elementos importantes en la AuthnRequest anterior son:

• Afirmación Servicio al Consumidor URL
• Destino URL
• Momento de la solicitud (emisión instantánea)
• ID de la solicitud
• Emisor

 

El servicio de consumidor de aserciónURL es la dirección del proveedor de servicios donde el IdP enviará el mensaje de respuesta una vez completada una autenticación.

 

El IdP URL comprueba el destino para validar que la solicitud de autenticación está realmente pensada para ello. Esto es útil para evitar que reenvío de solicitudes a destinatarios no deseados.

 

El IdP comprueba la hora de la solicitud para verificar si la solicitud realizada no era demasiado antigua.

IDde la solicitud es un número aleatorio generado y es importante que coincida con la respuesta de la solicitud.

 

El emisor identifica la entidad que generó el mensaje de solicitud. Normalmente, cada solicitud y respuesta contiene una entidad ID del remitente.

 

Otros elementos que deben tenerse en cuenta son los siguientes:

 

• Protocolo de enlace
• Firma
• Valor Resumen
• Certificado de X509

 

Enlace de protocolo es la referencia que identifica un enlace de protocolo que se URI SAML usará al devolver el mensaje de respuesta.

 

Signature y Digest Value se utilizan para garantizar la integridad del mensaje de los mensajes de solicitud y respuesta. Este valor se comprobará y validará en el lado receptor utilizando el mismo método de resumen (por ejemplo, SHA1) para garantizar la integridad del mensaje

 

Certificado X509: En SAML , la clave de certificado pública de intercambio e SP IdP entre sí. Los certificados entonces instalados y confianza explícitamente. Para establecer la confianza del origen de la llave, autoridad de certificación puede ser utilizado. La clave pública incluida en el mensaje AuthnRequest o respuesta es indicar a la pareja que la entidad con la correspondiente clave privada firma los mensajes. Simplemente determina que la clave pertenece a la otra parte.

 

Fig: SAML AuthnRequest FW GUI (y Chrome Dev Tool)

 

SAML AuthnRequest

Higo: RelayState

 

RelayState

 

SAML Respuesta de autenticación

 

Después de que el IdP autentica al usuario, crea una respuesta codificada en Base64 SAML y la reenvía al proveedor de servicios.

Como respuesta a AuthnRequest, el IdP envía a SP las aserciones de estado y seguridad. La respuesta contiene estado de éxito y aseveraciones en caso de que el usuario se autentica con éxito por los desplazados. En caso de cualquier otro fallo, la respuesta contendrá la situación indicando las razones de la falta y no contendrá ningún afirmaciones. IdP autentica al usuario y el SP no está involucrado en este proceso. SP sólo recibe el estado de la autenticación.

 

SAML Respuesta 

 

La mayoría de los elementos vistos en la SAML respuesta son similares a los que se describen en AuthnRequest. Los que no están cubiertos en AuthnRequest se discuten a continuación.

 

• Estado
• Name ID
• Índice de sesiones
• Declaración de atributo y valor de atributo
• Declaración de autenticación

 

El elemento status describe si el usuario se autenticó correctamente o no

 

NameID es un identificador único creado por IdP para gestionar el ciclo de vida de la sesión de seguridad principales de usuario después de una autenticación correcta (en este caso, el IdP se considera como autoridad de sesión)

 

Índice de sesión es el identificador único creado por idp para realizar un seguimiento de lo que SP el usuario/entidad de seguridad está haciendo SAML SSO (en este caso, SP se considera como participante de la sesión)

 

La instrucción Attribute contiene atributos asociados a un usuario. En el ejemplo anterior, samAccountName del usuario está siendo enviado por el IdP a SP .

 

La instrucción de autenticación contiene información como el tiempo y el método utilizados para garantizar la identidad del usuario

 

Fig: SAML Respuesta ( y Chrome FW GUI Dev Tool)

 

SAMLRespuesta Fig: RelayState

 

RelayState

 

SAML Solicitud de cierre de sesión

 

Cuando el usuario cierra sesión, el proveedor de Firewall GUI servicios crea una solicitud de cierre de SAML sesión para finalizar la sesión de usuario. La SLO solicitud se envía al IdP. NameID y el índice de sesión son utilizados por el IdP y SP para terminar la sesión de usuario. Idealmente, el IdP enviaría una SLO solicitud para todas las demás aplicaciones en las que el usuario ha iniciado SP sesión. Por lo tanto, cuando el usuario de una aplicación, el IdP intenta iniciar sesión el usuario de otra aplicación.

 

SAML Solicitud de cierre de sesión

 

Si la redirección se elige como SAML HTTP enlace para , entonces verá la firma de la solicitud de cierre de sesión que el SLO firmado en la SAML SP URL GET solicitud

 

Fig: SAML LogoutRequest FW GUI (y Chrome Dev Tool)

 

SAML Solicitud de cierre de sesión

SAML Respuesta de cierre de sesión

 

Para la SLO solicitud enviada al IdP por el , SP idp envía una respuesta de cierre de sesión que indica el éxito o el error. La respuesta será firmada por los desplazados. SPHace las limpiezas necesarias antes de cerrar el registro del usuario. Las SP cookies de sesión se borrarán que tiene para el usuario. La próxima vez, cuando el usuario intente iniciar sesión, todo el SAML proceso se reiniciará de nuevo. También SP puede borrar las cookies de sesión para el usuario en función del tiempo de inactividad de la sesión y reiniciar el SAML proceso de autenticación cuando el usuario intenta acceder a la aplicación de nuevo.

 

SAML LogoutResponse

 

Fig: SAML LogoutResponse FW GUI (y Chrome Dev Tool)

 

SAML LogoutResponse

 

Metadatos del IdP XML

 

El intercambio de confianza entre IdP y SP se puede facilitar fácilmente con los metadatos.

En el perfil del SP servidor ( o ), Firewall Panorama idp se puede crear utilizando el archivo de metadatos XML idp proporcionado. La información proporcionada en los metadatos se analiza y guarda en panaroma o Firewall configuración. Desplazados internos de metadatos puede contener la siguiente información:

 

• Entidad idp ID
• Idp SSO URL
• SSO formato de enlace ( SAML HTTP Enlace – POST /Redirect)
• Idp SLO URL
• SLO formato de enlace ( SAML HTTP Enlace – POST /Redirect)
• SAML Atributos
  • Nombre del atributo username
  • Nombre del atributo de grupo de usuarios
  • Nombre de atributo de función admin
  • Nombre de atributo de dominio de acceso
• Certificado de firma de IdP
• Bandera de WantAuthnRequestsSigned desplazados internos

 EntityDescriptor

 

SP Metadatos XML

 

SP metadatos se pueden exportar desde SAML perfil de autenticación desde Panorama / Firewall .Si IdP da una opción para cargar SP datos cumplidos, los metadatos exportados se pueden cargar en SP idp y la aplicación se SAML puede crear fácilmente. Como se mencionó anteriormente, los metadatos se pueden aprovechar para arrancar el proceso de confianza.

 

Los SP metadatos pueden contener lo siguiente:

 

• ACS URL
• ACS formato de enlace
• SLO URL
• SLO formato de enlace
• Entidad ID
• Certificado de firma

 

EntityDescriptor