Autenticación con otro proyecto de Bizagi usando OAuth 2.0

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Bizagi Studio > Definición de Seguridad > Seguridad del Portal de Trabajo > Autenticación del Portal de Trabajo > Autenticación con OAuth >

Autenticación con otro proyecto de Bizagi usando OAuth 2.0

Introducción

Esta sección describe como configurar OAuth en su proyecto de Bizagi, de tal manera que se delegue la autenticación a otro proyecto de Bizagi.

Para una mejor explicación paso a paso, el proyecto de Bizagi a configurar con OAuth se le conocerá como el proyecto Cliente, y el proyecto objetivo que se encargará de conceder el acceso se le conocerá como proyecto Servidor.

 

El siguiente diagrama muestra los pasos para autenticar un usuario cuando usa otro proyecto Bizagi.

 

Security_7

 

1. Redirigir al proveedor de identidad y validar las llaves del servidor OAuth. Cuando un usuario intenta acceder al proyecto del cliente Bizagi, esto redirige la solicitud al servidor Bizagi. Primero, el servidor Bizagi valida las claves OAuth (ID de cliente y Secreto de cliente) y el URI de redireccionamiento. SI alguno de estos no coincide, el cliente Bizagi muestra un mensaje de error.

2. El servidor Bizagi solicita las credenciales de usuario utilizando la página de inicio de sesión para el proyecto del servidor Bizagi.

3. Después de que el usuario ingresa las credenciales, el servidor de Bizagi valida las credenciales del usuario.

4. Si las credenciales proporcionadas por el usuario son correctas, el servidor Bizagi devuelve el token de autenticación, por lo que da acceso al Portal de trabajo del cliente Bizagi. Para este propósito, Bizagi tiene un servicio de devolución de llamada, que se configura como el URI de redireccionamiento, que espera la respuesta del servidor Bizagi en el procedimiento de autenticación utilizando el protocolo OAuth.

 

note_pin

Si planea utilizar un método de autenticación diferente a Bizagi y está realizando un deployment a un ambiente que no tiene información de usuarios (normalmente es el caso en el primer deployment de un proyecto), siga estos pasos para que pueda configurar adecuadamente sus usuarios y autenticación sin tener problemas para acceder al Portal de Trabajo:

1.Haga el deployment con el método de autenticación establecido como Bizagi. Esto le permite acceder al Portal de Trabajo con el usuario Admon sin proveer credenciales.

2.Una vez haya ingresado al Portal de Trabajo, ingrese manualmente sus usuarios o alternativamente puede utilizar en el método de su elección para sincronizar la información de sus usuarios a la tabla WFUser (SOAP, Sincronización LDAP, Archivo de Excel, o haciendo un procedimiento de sincronización de datos.

3.Haga un IISRESET para que el usuario Admon no pueda acceder al Portal de Trabajo.

4.Después de tener sus usuarios registrados en el Portal de Trabajo, use el Management Console para establecer el método de autenticación al que prefiera y se adecue a sus necesidades.

 

Si planea usar autenticación LDAP con sincronización periódica de usuarios, puede ignorar los pasos anteriores dado que solo necesitará esperar a que ocurra la siguiente sincronización para que sus usuarios puedan acceder el Portal de Trabajo.

 

Lo que debe hacer

Para configurar que el inicio de sesión del proyecto cliente dependa del proyecto servidor, siga estos pasos:

 

1. Asegúrese de que el proyecto servidor soporte OAuth.

2. Genere las llaves de acceso de OAuth.

3. Establezca el tipo de autenticación en el proyecto cliente, a través de Bizagi Studio.

4. Sincronice los usuarios de su proyecto servidor en el proyecto cliente.

 

note_pin

Los pasos orientados a configurar dicha integración, requieren detalles técnicos específicos (por ejemplo, endpoints y credenciales autorizadas) que normalmente las maneja el administrador de TI.

Por lo tanto, estos pasos requieren un perfil que tenga experiencia en estos asuntos, y con acceso a la información mencionada.

 

1. Asegúrese de que el proyecto servidor soporte OAuth.

En el proyecto de Bizagi del servidor, puede usar cualquier tipo de autenticación.

Primero necesita asegurarse que dicho proyecto haya sido creado en la versión 11.1 o mayor de Bizagi Studio, y que dicho proyecto no fue migrado de una versión previa de Bizagi 10.x.

 

2. Genere las llaves de acceso de OAuth.

Una vez se haya asegurado que el proyecto Servidor soporta OAuth de acuerdo a su versión, vaya al Portal de Trabajo y proceda a obtener las credenciales de OAuth (Client ID y Client secret) como se describe a continuación:

 

2.1 Registrar la aplicación OAuth.

Haga clic en la opción OAuth2 applications disponible en el menú de administración del Portal de Trabajo para añadir una aplicación externa.

 

OData_Workportal1

 

Esta opción lista los servicios que se acceden por los dispositivos Bizagi, pero le permite incluir aplicaciones adicionales que representan accesos concedidos a los servicios al proveer las llaves de acceso adecuadas.

 

2.2 Añadir nueva aplicación.

Haga clic en la opción para añadir un nuevo registro en la tabla:

 

OData_Workportal2

 

note_pin

Note que las configuraciones del sistema por defecto solo puede escoger la opción para editar la vida útil del token, esto determina el número de minutos después de los cuales expira un token (para aumentar la seguridad empleado por los tokens, especialmente con respecto a ataques de replay).

 

OData_Workportal15b

 

 

Al definir la nueva aplicación, asegúrese de considerar los siguientes detalles:

Nombre: Provea un nombre único y representativo.

Tipo de acceso: Para este escenario (conectar un proyecto cliente a uno servidor), use Código de autenticación.

Stio web: Especifique la URL de su proyecto cliente.

Contexto permitido: Para este escenario en particular, use Login.

Estrategia de redirección: Para esta prueba inicial y para uso general, establezca la estrategía como Aplicación web.

URI de redirección: Defina la URL a la que se dirigirán en los callbacks una vez el usuario entre sus credenciales.

Vida útil del token: Define la cantidad de minutos para los que un mismo token es válido y puede ser reusado por otras invocaciones (usualmente para mejorar la seguridad evitando ataques de Replay).

Una configuración usual o recomendada para la vida útil del token es que no sea mayor a los 15 minutos.

 

Cloud_OAuth3

 

Al terminar haga clic en Guardar.

Puede ver que su nueva aplicación registrada ahora se lista junto con sus llaves de acceso.

 

2.3 Copie las llaves de acceso cuando haya registrado la aplicación.

Las llaves de acceso que se necesitan el siguiente paso son: Client ID y Cliente Secret.

 

Cloud_OAuth4

 

3. Establezca el tipo de autenticación en el proyecto cliente, a través de Bizagi Studio.

Para escoger explícitamente autenticación Bizagi, siga estos pasos:

 

3.1 Abra su proyecto de Bizagi Studio.

Abra Bizagi Studio y cargue su proyecto (ambiente de desarrollo).

 

Cloud_OpenProj

 

2.2 Vaya a las configuraciones de seguridad.

Haga clic en la vista de Experto, y seleccione el módulo de Seguridad.

 

Cloud_SecurityModule

 

Haga clic en Autenticación en el panel de la mitad, asegúrese de que la lista desplegable en el panel de la derecha diga OAuth.

Luego, en la lista desplegable que aparece debajo, seleccione Bizagi.

 

Cloud_OAuth1

 

Haga clic en Actualizar si tenía una seleccione diferente.

Al seleccionar este tipo de autenticación, se listan nuevos parámetros:

 

Cloud_OAuth2

 

2.3 Configure los parámetros de OAuth

Refiérase al detalle de la siguiente tabla:

 

Parámetro

Descripción

URL del servidor proveedor de identidad de Bizagi

Define la URL del servidor Bizagi, para el proyecto servidor a cargo de autenticar a los usuarios.

Para Automation Service, esto se configura como sigue:

https://[ambiente]-[proyecto]-[empresa].bizagi.com

Client ID

Almacena el client ID generado en su aplicación OAuth registrada en el proyecto servidor.

Client Secret

Almacena el client secret generado en su aplicación OAuth registrada en el proyecto servidor.

Tipo de cookie

Define si Bizagi usa cookies persistentes o de sesión. El tiempo de espera para sesiones inactivas es el tiempo de vida para las cookies.

Habilitar el log de autenticación en la base de datos

Puede seleccionar esta opción para definir que la aplicación web debe registrar todos los eventos de autenticación (visto desde el Work Portal), de acuerdo a sus requerimientos de auditoría y expectativas.

Habilitar actualización de token

Habilita una actualización automática del token, de tal manera que los usuarias no tengan que proveer sus credenciales al expirar el token.

Con esta configuración, la expiración del token también se fuerza, solo que Bizagi trae un nuevo token automáticamente.

Habilitar cookie de Single Sign-On

Habilita una experiencia de usuario de Single Sign-On usando cookies.

URI de redirección

Define la URI de redirección para una autenticación exitosa.

Para Automation Service, se configura como:

https://[ambiente]-[proyecto]-[empresa].bizagi.com/oauth2/client/callback

Tiempo de espera para sesiones inactivas

Define los minutos para los que una sesión expire. De acuerdo a sus requerimientos y expectativas de autenticación (por ejemplo, 5 minutos).

Usar OpenID connect

Habilita el uso del protocolo OpenID.

Mostrar mensajes de error de autenticación detallados

Define si se muestran los errores de autenticación cuando ocurren.

 
4. Sincronice los usuarios de su proyecto servidor en el proyecto cliente.

Independiente del Administrador de Identidad escogido, siempre debe sincronizar las cuentas autorizadas en el Portal de Trabajo (si bien las contraseñas no son almacenadas en Bizagi en los sistemas de autenticación integrada)

Al sincronizar los usuarios con Automation Service, los usuarios son definidos únicamente por su dominio y nombre de usuario.

 

Hay diferentes alternativas para sincronizar usuarios. Refierase a Sincronizar usuarios.

 

Notas importantes

Tenga en cuenta estas restricciones en este caso en particular, al usar un proyecto cliente y servidor y el manejo de errores:

Los mensajes de error no están localizados en lenguajes diferentes (solo se muestran en inglés).

Los mensajes de error no son diferentes entre ambientes.

No se muestran páginas de error cuando falla la conectividad entre los proyectos, especialmente si se anida más de un proyecto bajo este tratamiento de la información.

Los registros no son guardado con mas detalles (esto es, el visualizador de eventos).

Las siguientes configuraciones en el proyecto servidor (aplican cuando se usa autenticación Bizagi) no son configurables para el proyecto cliente:

Habilitar cambio de contraseña luego del primer inicio de sesión, duración de cuenta inactiva antes de bloquear, o opciones para restaurar contraseñas.