Introducción
Bizagi ofrece integraciones con sistemas de administración de Identidad y Acceso (por ejemplo, Administradores de Identidad o Proveedores de Identidad) por medio de protocolos y estándares seguros de la industria.
Entre esos protocolos seguros, SAML 2.0 es soportado.
SAML 2.0 es el protocolo de la industria más ampliamente adoptado para autenticación, y los Administradores de Identidad mas reconocidos lo soportan.
Esta sección describe en alto nivel cómo funcionan la integración y los Administradores de Identidad, cuando se depende del protocolo SAML 2.0. Hay una serie de beneficios sobresalientes al integrar su administrador de identidad.
Dichos beneficios son:
1. Contar con una pantalla de inicio de sesión única y unificada a los usuarios finales.
Al integrar su administrador de identidad, Bizagi delegará la autenticación a el, y esto implica que los usuarios finales serán redirigidos a la pantalla de inicio de sesión provista por el administrador de identidad. Similarmente, los usuarios finales solo deberán recordar una combinación de usuario y contraseña (evitando administrar múltiples cuentas con sus contraseñas).
2. Centralizar su repositorio de usuarios y su sistema de autenticación.
Integrar su administrador de identidad reduce la carga administrativa que se produce cuando tiene múltiples sistemas de autenticación, dado que dichas tareas son necesarias periódicamente (como manejar cuentas inactivas, reiniciar contraseñas, etc.).
3. Forzar políticas de seguridad.
Utilizando su administrador de identidad, puede mejorar las medidas de seguridad al mismo tiempo que fuerza políticas de seguridad estrictas (como por ejemplo, políticas de contraseñas, características de las cuentas, perfiles, etc.).
Conectar su Administrador de Identidad usando SAML
La siguiente imagen ilustra cómo puede integrar su Administrador de Identidades con Bizagi, de tal manera que la autenticación sea delegada a su Administrador de Identidad.
Note del esquema anterior:
•Que su Proveedor de Identidad (o Proveedor de Confirmación de Identidad, conocidos como IdP), es responsable de proveer la autenticación por medio de confirmaciones estándar de SAML (tokens seguros).
•Bizagi se configura como un Proveedor de Servicios, que cede la autenticación al IdP, habiendo antes definido una relación de confianza entre ambos.
•Al usar un IdP, las contraseñas no son almacenadas en Bizagi y la arquitectura del sistema depende de HTTPS para la comunicación.
•Un Proveedor de Servicios se define como una Entidad (como un sistema) que tiene los servicios objetivo que los usuarios finales desean acceder. El IdP se define como el sistema al que se le confía la autenticación de los usuarios finales (permite SSO - Single Sign On) de tal manera que pueden acceder al contenido y servicios del Proveedor de Servicios.
El soporte de HTTPS en Bizagi se configura automáticamente con Automation Service.
|
Además de lo anterior, necesitará también certificados para firmar los mensajes que se intercambian (confirmaciones). Encriptar los mensajes es opcional y depende del soporte que su IdP tenga para esto. Puede usar el mismo certificado del servidor para todos los propósitos (debe estar en formato p12), aunque es una buena práctica usar certificados diferentes de acuerdo a su uso. Para los certificados que se emplean para firmar o encriptar mensajes, puede usar certificados auto-firmados sin implicar alguna falla de seguridad. Los certificados auto-firmados son los que no son emitidos por una CA pública, y puede generarlos usted mismo de manera local, usando herramientas de SDK como el keytool de Java, OpenSSL u otros. En caso de que vaya a utilizar un certificado auto-firmado y desee los pasos detallados para hacerlo, consulte el artículo Emitiendo e instalando certificados. De manera similar, podrá usar un certificado que ya pueda tener (p.e de la máquina local). |
Especificaciones técnicas
El soporte a SAML 2.0 considera seguir las características que se mencionan a continuación (de la especificación de SAML 2.0):
•Protocolo de Peticiones de Autenticación.
•HTTP Redirect Binding y HTTP POST Binding.
•Perfil de SSO del navegador, incluyendo:
oSP Redirect Request; IdP POST Response
oSP POST Request; IdP POST Response
oSingle Logout (SLO)
•Identity Provider Metadata - SSO Service Metadata.
Como se mencionó previamente, Bizagi requiere que las confirmaciones (aserciones) siempre estén firmadas (tanto para enviar como para recibir), aunque la encripción de dichas aserciones es completamente opcional (para enviar y recibir).
Los algoritmos de encripción soportados para los mensajes son: SHA1 y SHA256.
|
Note que SP significa Proveedor de Servicios (por sus siglas en inglés) y que IdP significa Identity Provider. |
Vea ejemplos y guias de configuración de diferentes proveedores de identidad. Vealos links abajo.
Posibilidades de autenticación integrada
Con el soporte de SAML 2.0, Bizagi soporta los siguientes sistemas de autenticación:
ADMINISTRADOR DE IDENTIDAD |
CARACTERÍSTICAS Y SOPORTE |
ESPECIFICACIONES TÉCNICAS (PROTOCOLOS Y ESTÁNDARES) |
|---|---|---|
Entra ID |
•El servicio de Entra ID se soporta como lo proveen los servicios cloud de Azure (desde una suscripción proveída por el cliente). •No requiere configuración de VPN. •Soporta SSO y SLO para sesiones activas del navegador (no a nivel de red). |
Hay dos opciones para conectarse con Entra ID: 1. Con SAML 2.0. 2. Con el protocolo OAuth 2.0 y su extensión de OpenID.
Para mayor información acerca de esta alternativa, refiérase a Autenticación con Entra ID. |
Microsoft Active Directory Federation Services (ADFS) |
•El soporte de ADFS está oficialmente certificado con la versión 3.0. •No requiere configuración de VPN. •Soporta SSO y SLO para sesiones activas del navegador (no a nivel de red). |
Hay dos opciones para conectar ADFS, se recomienda la primera. 1. Con SAML 2.0. 2. Con el protocolo WS-fedetation (implica WS-trust). El protocolo WS-federation usa aserciones basadas en la especificación del token de SAML, versión 1.1, aunque esto no cumple completamente con SAML.
Para mayor información acerca de esta alternativa, refiérase a Autenticación con ADFS |
NetIQ |
•NetIQ oficialmente certificado con la versión 4.4. •No requiere configuración de VPN. •Soporta SSO y SLO para sesiones activas del navegador (no a nivel de red). |
Depende de SAML 2.0.
Para mayor información acerca de esta alternativa, refiérase a Autenticación con NetIQ. |
Okta |
•Okta se soporta como un servicio cloud utilizado por el cliente. •No requiere configuración de VPN. •Soporta SSO y SLO para sesiones activas del navegador (no a nivel de red). |
Depende de SAML 2.0.
Para mayor información acerca de esta alternativa, refiérase a Autenticación con Okta. |
PingFederate |
•PingFederate está oficialmente certificado con la versión 8.4.3. •No requiere configuración de VPN. •Soporta SSO y SLO para sesiones activas del navegador (no a nivel de red). |
Depende de SAML 2.0.
Para mayor información acerca de esta alternativa, refiérase a Autenticación con PingFederate. |
SiteMinder |
SiteMinder está oficialmente soportado. |
Depende de SAML 2.0. |
|
Los proveedores de identidad que no se muestran explícitamente arriba pueden ser compatibles siempre que sean compatibles con SAML 2.0. En caso de cualquier problema contacte a nuestro equipo de soporte. Vea configuración general de SAML. |
Endpoints de Bizagi de SAML 2.0
Bizagi expone un conjunto de endpoints referentes a la autenticación SAML. Dichos endpoints le ayudan a configurar la autenticación y son los responsables de la comunicación entre Bizagi y su Proveedor de Identidad. Los endpoints son precedidos por:
Para Automation Service, la URL tiene este formato:
preceded by https://[environment]-[project]-[company].bizagi.com/
•/saml2/assertionConsumer
oProcesa las aserciones de respuestas SAML enviadas por el IdP.
•/saml2/logout
oProcesa las peticiones de cierre de sesión enviadas por el IdP.
•/saml2/metadata.xml
oDescarga el archivo de metadata de SAML del proyecto.
•/saml2/metadata.xml?mode=preview
oMuestra la metadata de SAML en el navegador.
Last Updated 9/11/2024 10:34:18 AM