Introducción
Bizagi soporta la integración con servicios de administración de identidad como el Directorio Activo de Azure (Entra ID) a través del soporte del protocolo OAuth 2.0 con la extensión OpenID.
Para acceder a información introductoria sobre las opciones de autenticación en Bizagi, refiérase a Autenticación.
Con esta configuración de OAuth en Bizagi, usted puede escoger delegar la autenticación a un servidor de Proveedor de Identidad que soporte dicho estándar. Entre otros proveedores que soportan el estándar, además de Entra ID, puede escoger la opción de autenticar a sus usuarios contra otro proyecto diferente de Bizagi que ya tenga configurado.
Cómo funciona OAuth 2.0
El framework define cuatro roles:
Propietario del recurso: es el usuario que conoce las credenciales para acceder a un recurso en particular. Esta suele ser una persona que intenta acceder a un sistema. En Bizagi, este sería un usuario que intenta acceder al Portal de Trabajo.
Cliente: por razones de seguridad, el servidor de recursos no habla directamente con el servidor de autorización, por lo que una brecha de seguridad en la comunicación entre el usuario y el servidor de recursos no expone las credenciales o la información segura. El cliente es una "aplicación" adicional que desea acceder a la cuenta de usuario en el servidor de autorización. Para hacer eso, el usuario debe dar permiso, para que el cliente pueda hablar con el servidor de autorización en su nombre.
Servidor de recursos: este servidor aloja la aplicación a la que el usuario desea acceder. Por lo general, el servidor de recursos y el servidor de autorización están integrados en una aplicación o API.
Servidor de autorización: este servidor contiene las cuentas y credenciales del usuario.
El siguiente diagrama describe el flujo de autorización general cuando un usuario trata de acceder a los recursos:
Para generar confianza entre el servidor de autorización / recursos y el cliente, primero debe registrar su aplicación. Cuando registra la aplicación, es importante definir un URI de redireccionamiento, también conocido como URL del callback. Esta URL se usa para redirigir al usuario cuando el usuario está autenticado y se le da el token de acceso o el código de autorización, para que el usuario pueda acceder a la aplicación.
Una vez que registre su aplicación en el servidor de autorización, esto le dará un par de claves OAuth:
ID de cliente: Identificador del cliente registrado en el servidor de autorización.
Secreto del cliente: contraseña para autenticar al cliente. Tenga cuidado de no confundir al cliente con el usuario. El cliente es una aplicación que habla en nombre del usuario.
Método de autorización (grant type)
Algunos pasos que se muestran en el flujo de autorización general arriba pueden ser diferentes según el método de autorización configurado. Bizagi admite los siguientes métodos de autorización:
Código de autorización: la aplicación obtendrá un código de autorización utilizando la URL de redireccionamiento. Este tipo de autorización se utiliza cuando necesita integrar aplicaciones web o móviles. Antes de obtener el token, el código de autorización debe enviarse al servidor de autorización. Este paso adicional disminuye la posibilidad de que los atacantes obtengan el token directamente. El siguiente diagrama resalta los pasos adicionales en el flujo general:
Nota: Este método es usado para la autenticación de usuario en el Work Portal.
Credenciales del cliente: este tipo de autorización se utiliza para obtener un token de acceso en el contexto de un usuario. Por ejemplo, obtener un token de acceso como el usuario administrador de Bizagi. Esto se usa cuando necesita usar una función de Bizagi sin considerar a todos los usuarios de la Aplicación. Por ejemplo, cuando desea utilizar la capa OData, como usuario admon. Con este tipo de autorizción, no es necesario enviar un código de autorización, y las llaves OAuth se validan directamente para obtener el token de acceso.
Portador del token (bearer token): este tipo de autorización se utiliza como un esquema de autenticación HTTP, por lo que una aplicación externa que utiliza el par de llaves OAuth puede obtener un token de acceso enviando directamente estas llaves en el encabezado de autorización de la solicitud HTTP. Por ejemplo, cuando sincroniza usuarios usando SCIM. Este tipo de concesión se recomienda bajo una conexión segura HTTPS.
Nota: Las credenciales de cliente y Portador del token se utilizan para funcionalidades integración como SCIMy OData. Estos métodos no están disponibles para la autenticación de usuarios en el Portal de Trabajo.
Autorización (OAuth) vs Autenticación (OpenID)
La autenticación es el procedimiento para identificar a un usuario o una persona. El procedimiento de autenticación valida que un usuario es lo que dice ser. Hay diferentes formas de validar eso, por ejemplo, biometría o contraseñas, como generalmente se hace en TI. Por otro lado, la autorización es un procedimiento para dar acceso a un conjunto definido de recursos una vez que un usuario se autentica. OAuth 2.0 es un protocolo de autorización pero no es capaz de identificar usuarios. Por lo tanto, Bizagi usa el estándar OpenID, por lo que le da capacidades de autenticación a Bizagi.
OpendID es una capa en la parte superior del protocolo OAuth 2.0 para que los sistemas puedan autenticar a un usuario utilizando el mismo protocolo. En Bizagi, el estándar OpenID se usa para la autenticación de usuarios.
Proveedores de identidad de autenticación OAuth 2.0
A través de esta configuración de OAuth en Bizagi, puede elegir delegar la autenticación a un servidor de proveedor de identidad que admita dichos estándares. Entre otros servidores de proveedores de identidad que admiten el estándar, puede elegir:
Parámetros de configuración de OAuth 2.0
Bizagi tiene los siguientes parámetros de configuración cuando configura el tipo de autenticación OAuth. Algunos de los parámetros cambian según el proveedor de identidad seleccionado:
Parámetro |
Descripción |
|---|---|
URL del servidor proveedor de identidad |
Define la URL del servidor Bizagi, para el proyecto servidor a cargo de autenticar a los usuarios. |
Client ID |
Almacena el client ID generado en su aplicación OAuth registrada en el proveedor de identidad. |
Client Secret |
Almacena el client secret generado en su aplicación OAuth registrada en el proveedor de identidad.
*No está disponible para el tipo de autorización implicit |
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.
*Solamente disponible para Bizagi como proveedor de identidad. |
Habilitar cookie de Single Sign-On |
Habilita una experiencia de usuario de Single Sign-On usando cookies.
*Solamente disponible para Bizagi como proveedor de identidad. |
OAuth2 Authorization Endpoint |
Debe coincidir con el endpoint de autorización de OAuth 2.0 según su Entra ID. Use la siguiente URL: https://login.microsoftonline.com/[tenant]/oauth2/authorize
Considere: •[tenant]: Debe especificar su ID de tenant (según la suscripción de su Azure).
*Solamente disponible para Entra ID como proveedor de identidad. |
Token Endpoint |
Debe coincidir con el punto final del token de OAuth 2.0 según su Entra ID. Use la siguiente URL: https://login.microsoftonline.com/[tenant]/oauth2/token
Considere: •[tenant]: Debe especificar su ID de tenant (según la suscripción de su Azure).
*Solamente disponible para Entra ID como proveedor de identidad. |
URI de redirección |
Define la URI de redirección para una autenticación exitosa. |
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). |
Mostrar mensajes de error de autenticación detallados |
Define si se muestran los errores de autenticación cuando ocurren. |
Endpoints de Bizagi de OAuth
Los endpoints que Bizagi provee respecto a autenticación OAuth para manejar las comunicaciones con terceros son (precedidos por https://[project_environment]-[your_project]-[your_company].bizagi.com/[your_project]-[project_environment]):
•/oauth2/server/authorize
oManeja peticiones de autorización de terceros.
•/oauth2/server/token
oManeja peticiones de tokens de terceros.
•/oauth2/client/callback
oManeja los códigos de respuesta de un Servidor de Autorización.
•/oauth2/server/logout
oInvalida un token.
Last Updated 9/11/2024 10:34:19 AM