Inicio de Sesión con federación de usuarios
Esta funcionalidad tiene como objetivo permitir a los usuarios de Finnegans ingresar al sistema mediante un proveedor de identidades externo
¿Para qué sirve?
Permite a los usuarios tener acceso a múltiples aplicaciones ingresando solo con una cuenta a los diferentes sistemas y recursos. De esta manera, podrás ingresar a Finnegans utilizando el sistema de identificación que utiliza tu empresa.
Actualmente, podés acceder al sistema a través de usuario y contraseña y también utilizando Google. A estas formas de acceder, agregamos la opción “Ingreso con SSO” de modo que puedan identificarse solo una vez, manteniendo la sesión válida para el resto de las aplicaciones que hacen uso del SSO.
Antes de empezar
Antes de utilizar esta funcionalidad, será necesario solicitar la activación del servicio a FINNEGANS, para eso deberás contactarte con Finnegans a través de comercialclientes@finnegans.com.ar o a customercare@finneg…com.
Este servicio no tiene costo adicional.
Deberás realizar algunas configuraciones iniciales en el sistema.
Configurar el servicio
- Ingresar al Menú → Espacio de Trabajo
- Completar la información en la solapa “Federación de Identidad Externa”
- Nombre: Nombre con el cual se va identificar la federación
- Descripción
Icono_URI: URL del icono
Protocolo: OAuth 2.0+OpenID Actualmente soportamos el protocolo OpenID con OAuth 2.0 (Comúnmente llamado OIDC), se utilizan en combinación para proporcionar la autenticación de usuarios en la aplicación de manera segura.
ClientID: Es un identificador único asignado al cliente (aplicación o servicio) por el proveedor de identidad (IdP) durante el registro de la aplicación en el proveedor. Cada cliente registrado en el proveedor de identidad tiene un clientID único que actúa como identificador para esa aplicación. Cuando el cliente desea autenticarse con el proveedor de identidad, incluirá el clientID en las solicitudes OIDC para que el proveedor pueda identificar y reconocer la aplicación que está intentando acceder a recursos protegidos.
SecretKey: Es una cadena de caracteres secreta y confidencial que se comparte únicamente entre el cliente (aplicación o servicio) y el proveedor de identidad. El secretKey se utiliza para autenticar y verificar que el cliente es quien dice ser. Generalmente, el secretKey se usa en combinación con el clientID para obtener tokens de acceso válidos. Esta combinación de clientID y secretKey es conocida como “credenciales del cliente” y debe mantenerse segura y privada, ya que cualquier entidad que tenga acceso a estas credenciales podría hacerse pasar por el cliente y acceder a los recursos protegidos.
Auth_URI: Especifica la dirección del servicio o punto de acceso donde los usuarios serán redirigidos para iniciar el proceso de autenticación antes de acceder a las aplicaciones o servicios protegidos por SSO. Allí, el usuario deberá proporcionar sus credenciales (como nombre de usuario y contraseña) o realizar otro proceso de autenticación, como utilizar un token o una clave de seguridad.
Token_URI: Ingresar la dirección a la que Finnegans enviará una solicitud para obtener un token de acceso después de que el usuario ha sido autenticado correctamente, intercambiando el código obtenido en el paso anterior.
Es importante tener en cuenta que la configuración de access_token URL debe ser precisa y segura, ya que es una parte crítica del flujo de autenticación y autorización de SSO. Si este punto final es comprometido o configurado incorrectamente, podría haber graves problemas de seguridad, como acceso no autorizado a los recursos protegidos o suplantación de identidad.
Redirect_URI: Ingresar la dirección a la que el proveedor de identidad redirige al usuario después de que ha sido autenticado. Esta URL es donde se envía el token de acceso para permitir el acceso a Finnegans. La URL a utilizar debe ser https://go.finneg.com/auth/generic/auth
UserInfo_URI: Ingresar la URL a la que Finnegans enviará la solicitud para obtener información adicional del usuario una vez que ha sido autenticado y autorizado correctamente. El formato de la respuesta debe encontrarse dentro del claims estándar. Por ejemplo:
{
“sub”: “ID”,
“name”: “Nombre”,
“email”: “example@example.com”,
“picture”: “https://example.com/john_doe.jpg”
}
Scope: El “scope” en una autenticación con OpenID Connect (OIDC) es un parámetro utilizado durante el proceso de solicitud de autorización para especificar qué información se quiere obtener del proveedor de identidad. Los scopes definen qué recursos y qué acciones se desean autorizar en nombre del usuario.
El parámetro scope se envía en la solicitud de autorización a través del flujo de autorización de OIDC, y puede contener uno o varios valores que representan los diferentes alcances que se solicitan. Cada valor de scope representa un conjunto de permisos específicos.
Por ejemplo, algunos de los scopes comunes en OIDC son:
openid: Este scope es obligatorio para usar OIDC y establece que la solicitud se realiza como parte de una autenticación con OpenID Connect.
profile: Este scope solicita información básica del perfil del usuario, como su nombre, apellido, nombre de usuario, etc.
email: Solicita acceso a la dirección de correo electrónico del usuario.
address: Solicita acceso a la dirección del usuario.
phone: Solicita acceso al número de teléfono del usuario.
offline_access: Este scope solicita que se emita un “refresh token” que permita obtener un nuevo token de acceso cuando el token actual expire, sin necesidad de pedir al usuario que inicie sesión nuevamente.
El alcance de los scopes puede variar según el proveedor de identidad y las políticas de autorización establecidas. Algunos proveedores de identidad pueden requerir que las aplicaciones clientes están preconfiguradas para solicitar scopes específicos.
Es importante tener en cuenta que el proveedor de identidad debe estar configurado para permitir que las aplicaciones cliente soliciten ciertos scopes y que el usuario debe otorgar el consentimiento para que la aplicación acceda a los datos representados por los scopes solicitados. Los scopes ayudan a establecer un nivel de autorización granular y a proteger la privacidad del usuario al controlar qué información puede acceder una aplicación.
- GUARDAR para registrar la información.
Cerrar la sesión y comenzar a hacer uso de la funcionalidad. Los usuarios del espacio de trabajo podrán ingresar a través de SSO.
Ejemplo
Configuramos Proveedor de servicio: OKTA
Modo de uso
- Ingresar a la URL de login, completar usuario y Espacio de Trabajo.
- Presionar “Ingresa con SSO”
- El sistema te redirigirá a la instancia de verificación de identidad utilizada, completar con tus datos personales.
Iniciamos sesión con los datos del Ejemplo:
4. Listo! Sesión iniciada.
