--- title: "Autenticación en aplicaciones mediante federación de identidades" slug: "autenticacion-en-aplicaciones-mediante-federacion-identidades" updated: 2024-11-29T10:49:46Z published: 2024-11-29T10:49:46Z canonical: "docs.fundanetsuite.com/autenticacion-en-aplicaciones-mediante-federacion-identidades" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.fundanetsuite.com/llms.txt > Use this file to discover all available pages before exploring further. # 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*](https://learn.microsoft.com/es-es/entra/external-id/invitation-email-elements#explaining-the-email) 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. > [!CAUTION] > 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**](/v1/docs/autenticacion-en-aplicaciones-mediante-federacion-identidades#¿qué-es-el-protocolo-de-autenticación-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. Aviso Una vez establecido este método de autenticación para la aplicación se anulará cualquier otro método de autenticación, por lo que todos los usuarios de la misma deberán poder autenticarse en el IdP del cliente. - 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. Pasos a producción Los pasos a producción se realizan de Lunes a Jueves de 7:30 a 8:30 ## ¿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: ![](https://cdn.document360.io/8f31c892-f75a-4781-bcfa-df65db9d475e/Images/Documentation/image-1686226229732.png) 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.