Autenticación con SAML

<< Clic para mostrar Tabla de Contenidos >>

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

Autenticación con SAML

Introducción

Bizagi ofrece integraciones con sistemas de administración de Identidad y Acceses (por ejemplo, Administradores de Identidad o Proveedores de Identidad) por medio de protocolos y estándares seguros de la industria.

Entre esos protocoles 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.

Para información introductoria sobre las opciones de Autenticación en Bizagio, refiérase a Administración de identidad y accesos.

 

Se recomienda enfáticamente integrar su Administrador de identidad corporativo con Bizagi (para usar una autenticación Federada).

En caso de que no desee integrar su adminsitrador de identidad, puede utilizar en la autenticación local de Bizagi.

Si bien la autenticación local de Bizagi ofrece características de inicio de sesión seguras (como HTTPS y encripción de contraseñas en reposo) y parámetros de configuración que le permiten forzar políticas de contraseñas o cuentas (como longitudes máximas o mínimas, intentos, etc.), hay una serie de beneficios sobresalientes al integrar su adminsitrador 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.

En términos de usabilidad, esto evita tener que presentar diferentes pantallas de inicio de sesión (de diferentes aplicaciones con las que sus usuarios trabajan).

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 si 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.).

Al integrar su administrador de identidad, las contraseñas no son almacenadas en Bizagi y el manejo de identidad y acceso es hecho completamente por el administrador de identidad.

 

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.).

Por ejemplo, puede usar autenticación multi-factor en caso de que sea soportado por su administrador de identidad.

 

4. Proveer una mejor experiencia de usuario a los usuarios finales.

Los usuarios finales que acceden Bizagi desde cualquier ubicación o dispositivo, utilizarán protocolos estándares.

Sin importar el tipo de autenticación, Bizagi soporta protocolos seguros como HTTPS para todas las comunicaciones.

Para todas las opciones que integran un administrador de identidad, excepto para una integración punto a punto LDAP, el uso de protocolos web es empleado (como SAML 2.0). Dichos protocolos habilitan una experiencia de SSO.

 

 

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.

 

 

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.

 

Federated Authentication_SAML

 

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 aquitectura 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.

 

Respecto a HTTPS, considere:

Su IdP se debe configurar de tal manera que soporte HTTPS. Para ello, debe contar con un certificado válido y al día para instalar en su servidor de IdP.

El soporte de HTTPS en Bizagi se configura automáticamente con <%BIZAGI_CLOUD%>. Por otro lado, para proyectos locales (on-premises), necesitará un certificado similar y al día para instalar en su servidor de Bizagi.

A los certificados para este uso se les refiere como certificados de servidores SSL/TLS.

Los certificados válidos (por ejemplo para su ambiente de producción) necesitan corresponderse a los expedidos o reconocidos por una Autoridad de Certificados (CA) válida.

 

note_pin

Además de lo aterior, 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_pin

Note que SP significa Proveedor de Servicios (por sus siglas en inglés) y que IdP significa Identity Provider.

 

Cómo se configura la autenticación con SAML

Para integrar su IdP que cumple con SAML con Bizagi, necesitará generar e instalar previamente sus propios certificados.

Dichos certificados se emplean en la integración con el propósito de firmar las aserciones.

Este paso no se realiza en Bizagi y no está restringido por algún requerimiento especial por Bizagi (por lo general se lleva a cabo por su parte).

 

Partiendo de esto, la siguiente lista describe los pasos que se deben realizar, tanto en el IdP como en Bizagi:

 

1.Establecer en Bizagi las configuraciones con referencia a la especificación de su funcionamiento de SAML.

En estas configuraciones, usted establecerá:

Permitir encripción de aserciones: escoja esta opción (poner en encendido) para encriptar las aserciones generadas por Bizagi.

Permitir las trazas de autenticación en la base de datos: escoja esta opción para definir si la aplicación web debe registrar las trazas de todos los eventos de autenticación (se ve desde el Work Portal).

Certificado de encripción: Use el botón de Navegar, para subir el certificado digital (en formato P12, que contiene las llaves públicas y privada) que serán usadas para encriptar las aserciones generadas por Bizagi.

Aplica cuando la propiedad de encripción de aserciones está seleccionada.

Si bien es posible reutilizar el mismo certificado para las firmas, se recomienda usar uno diferente, especialmente en ambientes de producción.

Se permite el uso de certificados auto-firmados.

El formato P12 es equivalente al formato PFX (si ya cuenta con un PFX sencillamente puede renombrar ese archivo cambiandole la extensión).

Contraseña del certificado de encripción: escriba la contraseña para el certificado digital, como se utilizó para la encripción.

Aplica cuando la propiedad Permitir encripción de aserciones está seleccionada.

Forzar autenticación: marque esta opción para evitar las capasidad de SSO, de tal manera que cada vez que un usuario intente entrar a Bizagi, las credenciales sean pedidas explícitamente.

Ruta del archivo de metadata del IdP: Escriba la ruta donde se encuentra el archivo de metadata del IdP. Esta ubicación es por lo general una URL. Para proyectos locales de Bizagi, se puede usar una ruta completa de disco, siempre y cuando se tengan los permisos de acceso adecuados.

Time-out de sesiones inactivas: Defina los minutos que tomará una sesión en expirar.

Nombre de la Organización: Escriba el nombre de su organización. Dicha información se inluye con los mensajes de petición enviados por Bizagi.

URL de la Organización: Escriba la URL del sitio web de su organización. Dicha información se incluye con los mensajes de petición enviados por Bizagi.

Protocolo Binding de SAML para SLO: Seleccione POST o REDIRECT para definir que implementación de Binding usar para SLO (Cerrado de sesión único).

Considere que al seleccionar REDIRECT puede no ser óptimo al encriptar aserciones, dado que dichos mensajes serían enviados mediante la URL y se volverían más largos, potencialmente causando errores en algunos navegadores web.

Protocolo Binding de SAML para SSO: Seleccione POST o REDIRECT para definir que implementación de Binding usar para SSO (Inicio de sesión único).

Considere que al seleccionar REDIRECT puede no ser óptimo al encriptar aserciones, dado que dichos mensajes serían enviados mediante la URL y se volverían más largos, potencialmente causando errores en algunos navegadores web.

URL del Proveedor de Servicios: Escriba la URL completa (incluyendo el proyecto) del SP. Esto significa entrar la URL para el Work Portal de Bizagi. Para <%BIZAGI_CLOUD%>, la URL usa este formato:

https://[ambiente]-[proyecto]-[organización].bizagi.com/, y para proyectos locales, la URL usa el siguiente formato:

https://[servidor]/[proyecto]/.

Recuerde que la URL anterior es sensible a mayúsculas y minúsculas, y que para <%BIZAGI_CLOUD%>, [Ambiente] debe ser omitido (dejado en blanco) cuando se está en producción.

Contraseña del certificado de firma: Escriba la contraseña para el certificado digital usado para firmar las aserciones.

Algortimo de firma: Seleccione SHA1 o SHA256 para definir cuál algoritmo se va a usar para firmar las aserciones.

Certificado de firma: Utilice el botón Navegar para subir el certificado digital (en formato P12, que contiene las llaves pública y privada) que se va a utilziar para firmar las aserciones generadas por Bizagi.

Se permite usar certificados auto-firmados.

El formato P12 es equivalente al formato PFX (si ya cuenta con un PFX sencillamente puede renombrar ese archivo cambiandole la extensión).

Dirección de e-mail de contacto técnico: proporcione una dirección de e-mail de contacto con su organización, para asuntos técnicos. Esta información se incluirá en los mensajes de petición enviados por Bizagi.

 

Note que los valores entrados para las configuraciones anteriores, serán encriptados por Bizagi al guardar.

Después de completar este paso, se crea un archivo metadata.xml para que sirva como entrada al siguiente paso.

 

2. Configurar a Bizagi como Proveedor de Servicios en si Proveedor de Identidad.

Al ir a las opcones de administrador de su IdP, debe poder registrar a Bizagi como un SP de confianza.

En este paso, usualmente debe especificar/confirmar la URL de Bizagi como SP de confianza, además de cargar el archivo de metadata.

Junto con esta configuración, usted definirá el certificado a utilizar para firmar las aserciones y definirá qué información es enviada exactamente dentro de ellas (p.e, típicamente el identificador único de usuario: email).

La configuración relacionada a encripción de aserciones es opcional, y depende de si su IdP lo soporta.

Los pasos exactos que logran esto pueden variar gráficamente entre IdP's, no obstante, los mismos conceptos aplican.

 

Vea un ejemplo y los pasos guía para los diferentes IdP's como se referencia abajo.

 

note_pin

Una vez que sus usuarios sean sincronizados en Bizagi, y se haya configurado la autenticación con SAML 2.0 en Bizagi y en su IdP, los usuarios finales que accedal al Work Portal serán presentados automáticamente con la pantalla de inicio de sesión de su IdP.

Cuando los usuarios ya hayan iniciado sesión y ésta sea válida, no necesitarán entrar sus credenciales.

 

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)

Azure AD

El servicio de Azure AD se soporta como lo proveen los servicios cloud de Azure (desde una subscripció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 Azure AD:

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 Azure AD.

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.

 

note_pin

Los administradores de identidad que no hayan sido mencionados anteriormente no están oficialmente soportados o certficados.

Esto significa que puede utilizar un administrador de identidad SAML diferente, pero es recomendable que lo consulte primero con nuestro equipo de soporte.

Para información de alto nivel sobre el funcionamiento de la autenticación usando un administrador de identidad SAML, refiérase a Autenticación via 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 https://[project_environment]-[your_project]-[your_company].bizagi.com/[your_project]-[project_environment]):

 

/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.