Autenticación en aplicaciones mediante federación de identidades

Objetivo

Configurar el método de autenticación de las aplicaciones Web y/o de escritorio (a través de cliente Citrix Workspace) de FundanetSuite Cloud para utilizar credenciales propias del cliente.

Acceso aplicaciones de escritorio (Citrix)

Requisitos

El cliente deberá disponer de un tenant de Azure Entra ID o Microsoft 365 con los usuarios que vayan a hacer uso de las aplicaciones.
No es necesaria ninguna configuración por parte del cliente o Semicrol para utilizar este método.

Procedimiento

Para el acceso a las aplicaciones de escritorio a través de Citrix se utilizará Azure Entra ID. En este caso se realiza una colaboración B2B en la que se invita al usuario final al tenant de fundanetsuite.com mediante correo electrónico. El usuario debe aceptar la invitación y a partir de ese momento puede acceder a las aplicaciones citrix mediante su correo electrónico y contraseña corporativos.

Importante

En la colaboración B2B mediante Azure Entra ID se da por hecho que el correo electrónico y el nombre principal del usuario (UPN) es el mismo. En caso contrario se debe comunicar a Semicrol tanto el correo electrónico como el UPN del usuario.

Acceso aplicaciones web

Requisitos

El cliente debe disponer de un IDP que soporte el protocolo SAML v2 en el que estén dados de alta los usuarios que vayan a hacer uso de las aplicaciones web. Algunos de los IDPs validados son: Shibboleth, Azure Entra ID, Oracle ID y SimpleSamlPhP. Se configurará una relación de confianza entre el SP de FundanetSuite y el IDP del cliente mediante un intercambio de información.

Procedimiento

Se debe acordar el atributo de la cuenta a correlacionar por Semicrol para validar a los usuarios. Este atributo suele ser la dirección de e-mail, el UPN o el ePPN de la cuenta. Una vez acordado qué atributo utilizar Semicrol utilizará este atributo para configurar el código de los usuarios.

• Por parte del Cliente: Se debe configurar un IDP que soporte el protocolo SAML v2 para su dominio de autenticación. El extremo de conexión del IDP (endpoint) debe ser público en Internet y debe exponerse a través de https. El cliente debe facilitar a Semicrol:

  • Entity ID Literal identificativo configurado para establecer la relación de confianza con las aplicaciones Web de Fundanetsuite.

  • Url del archivo de metadatos del IdP.

  • Certificados para firmar las aserciones, estos certificados se suelen incluir en el archivo de metadatos.

  • Facilitar las credenciales de una cuenta del dominio del cliente para mantenimiento de la aplicación.

Después,

• Por Parte de Semicrol: Se debe configurar un SP para la aplicación Web que va a utilizar el protocolo SAML v2 para autenticar a las cuentas de los usuarios del cliente. En el SP se configurará el atributo de la cuenta de usuario a correlacionar que se utilizará para validar la cuenta en la aplicación. Semicrol debe proporcionar al cliente:

  • Entity ID Literal identificativo configurado para establecer la relación de confianza con el dominio del cliente.

  • Url del archivo de metadatos del SP.

  • Certificados para firmar las aserciones, estos certificados van incluidos en el archivo de metadatos.

Tras la provisión del IdP y del SP se realizarán pruebas con la cuenta facilitada para comprobar el correcto funcionamiento de la autenticación. A partir de ese momento, se fijará un día para el paso a producción de la aplicación con este método de autenticación.

¿Qué es el protocolo de autenticación SAML v2?

El protocolo SAML v2, que significa Security Assertion Markup Language versión 2, es un estándar de seguridad utilizado para el intercambio de información de identidad y autenticación entre diferentes sistemas. Básicamente, es un conjunto de reglas y formatos que permiten a una aplicación (como un sitio web o una aplicación en la nube) solicitar a un proveedor de identidad (como Azure Entra ID) que autentique a un usuario en su nombre. El SAML v2 permite que la autenticación se realice de manera segura, sin que la aplicación tenga que almacenar o manejar las credenciales del usuario directamente. En cambio, se utiliza un intercambio de mensajes cifrados para demostrar la identidad del usuario y garantizar la confiabilidad de la información transmitida.

El uso de este protocolo requiere la provisión de los siguientes componentes:

• Proveedor de Identidad (IdP, por sus siglas en inglés): El Proveedor de Identidad es responsable de autenticar a los usuarios y proporcionar información sobre su identidad. Cuando un usuario intenta acceder a una aplicación protegida, el IdP verifica las credenciales del usuario y emite un token de seguridad llamado SAML Assertion, que contiene información sobre la identidad del usuario. Este token es enviado al Proveedor de Servicios (SP) para permitir el acceso a la aplicación.

• Proveedor de Servicios (SP, por sus siglas en inglés): El Proveedor de Servicios es la aplicación o servicio que requiere la autenticación del usuario. Actúa como el receptor del SAML Assertion emitido por el IdP. El SP es responsable de validar y procesar ese Assertion para permitir o denegar el acceso a la aplicación protegida.

En el diagrama siguiente se muestra cómo sería el proceso de autenticación de un usuario al intentar autenticarse en una aplicación web configurada para autenticar a los usuarios contra el IdP de un determinado dominio:

1. El usuario accede a la aplicación Web que requiere autenticación con su navegador web y el SP intercepta la petición para comenzar el proceso de autenticación.

2. El SP genera una solicitud de autenticación, después envía esta solicitud y el usuario al IpD de usuario.

3. El IdP autentica al usuario, entonces envía una respuesta de autenticación y el usuario de vuelta al SP.

4. El SP verifica la respuesta del IdP y envía la solicitud a través a la aplicación Web la cual devuelve a usuario el contenido de la misma.