Introducción
El Portal de Trabajo es una aplicación web que le permite a cada uno de sus usuarios realizar sus tareas y configuraciones correspondientes. En su condición de aplicación web, antes de trabajar en la aplicación, cada usuario debe identificarse ante el sistema de tal manera que solo las personas esperadas puedan realizar dichas actividades.
Este concepto de identificar a un usuario en un sistema se conoce como Autenticación. Esta sección cubre todo lo que debe saber acerca de la autenticación y todo lo que debe configurar en Bizagi de acuerdo a sus necesidades de negocio.
¿Qué es Autenticación?
En términos simples, la autenticación es el proceso de confirmar la identidad de un usuario contra un sistema. En otras palabras, es determinar si alguien o algo es de hecho quien dice ser.
Este concepto tiene su propio significado y utilidad en tecnología, en donde provee control de acceso a los sistemas al chequear si las credenciales provistas por un usuario corresponden a las que estaban almacenadas previamente en la base de datos de usuarios autorizados (lo cual puede ser administrado de diferentes maneras, como se describe en esta sección). La siguiente imagen ilustra cómo un usuario pide acceso a recursos del Portal de Trabajo, pero debe ser autenticado previamente para que se otorgue el acceso a dicha información.
Es común la confusión entre Autenticación y Autorización, y si bien los conceptos están relacionados son bastante diferentes. La autenticación se encarga de permitir o denegar el acceso de un usuario a un sistema, mientras que la autorización se encarga de permitirle a un usuario hacer únicamente lo que le es permitido. Por ejemplo, si los asistentes tienen permitido revisar cierta información pero no editarla, es el módulo de autorización el responsable de esto funcione de esa manera.
Alternativas de autenticación para el Portal de Trabajo
|
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. |
Hay muchas maneras de implementar el sistema de Autenticación del Portal de Trabajo, aquí son descritas de manera general, pero en esta sub-jerarquía de la guía de usuario puede encontrar información adicional de cada una de ellas.
El siguiente diagrama muestra los protocolos de autenticación para una aplicación Bizagi desde un servidor local (on premises), muestra además el tipo de experiencia de usuario que ofrecen y si el método es recomendado.
•Autenticación Federada
Este protocolo de autenticación delega la responsabilidad de identificar y autenticar al usuario a un servidor tercero, tal como se muestra en la imagen de abajo.
Hay dos protocolos de autenticación federada soportados:
oSAML 2.0: Con este tipo de autenticación Bizagi delega el procedimiento al Administrador de Identidad de su elección (Bizagi soporta integración con Azure AD, ADFS, NetIQ, Okta, PingFederate y SiteMinder) quien manejará la información mediante mensajes seguros a través del protocolo estándar SAML. Le recomendamos usar este tipo de autenticación ya que es ampliamente adoptado por la industria y puede ser configurado con muchos proveedores. Para mayor información acerca de este método refiérase a Autenticación con SAML.
oWS-Federation: Este tipo de autenticación se realiza delegando la información a un servidor ADFS que ha sido configurado con este protocolo. Los mensajes se envían usando los estándares WS-Federation y WS-Trust con aserciones SAML 1.1, las cuales no cumplen con el estándar SAML 2.0. Para mayor información sobre este método, refiérase a WS-Federation.
|
Aunque hay dos protocolos compatibles. Recomendamos usar SAML 2.0 sobre WS-Federation. SAML 2.0 es un estándar común en la industria que es compatible con una amplia gama de sistemas en su organización. |
•Autenticación Windows: Este tipo le permite a Bizagi validar los usuarios contra dominios y máquinas Windows automáticamente. Esto se realiza delegando la autenticación a la máquina Windows del lado del cliente (las contraseñas no son almacenadas en Bizagi). También puede hacer que Bizagi tome las credenciales de la sesión Windows automáticamente para evitar una página de inicio de sesión (experiencia SSO a nivel de red). Para mayor información al respecto, refiérase a Autenticación Windows.
•OAuth: Este tipo de autenticación usa los protocolos OAuth y OpenID Connect para que su proyecto de Bizagi delegue la autenticación a un proveedor de identidad como por ejemplo otro proyecto de Bizagi. For more information about this alternative, refer to OAuth authentication.
•LDAP Authentication: Este tipo de autenticación soporta integración con un Microsoft AD on premises y utiliza el protocolo estándar LDAP (por ejemplo, conectarse vía una URL LDAP con filtros como lo soporta el formato LDAP). Ofrece una experiencia de Same Sign-On. Para mayor información al respecto, refiérase a Autenticación LDAP.
•Autenticación Bizagi: Esta alternativa usa la autenticación local de Bizagi, le permite forzar sus políticas de seguridad para contraseñas y cuentas pero usa el mecanismo interno de Bizagi que almacena la información en su misma base de datos. Para mayor información de este tema, refiérase a Autenticación en Bizagi.
oAutenticación Mixta: Este tipo de autenticación le permite usar dos métodos diferentes de autenticación para administrar los usuarios desde dos dominios diferentes. Uno de esos tipos tiene que ser autenticación Bizagi y el otro puede ser Windows o Personalizada. Esta es la alternativa recomendada para los casos en los que tendrá usuarios de negocio y externos en su aplicación. Para más información sobre esta alternativa, refiérase a Autenticación mixta.
•Autenticación personalizada: esta alternativa permite que la autenticación sea administrada por una aplicación externa. Con autenticación personalizada puede desarrollar su propio componente que sobrescriba métodos de el componente de autenticación de Bizagi. De esta manera el componente desarrollado puede usar cualquier API o componente tercero y conexiones para autenticar al usuario. Para más información sobre esta alternativa, refiérase a Autenticación personalizada.
Alternativas de experiencia de usuario en autenticación
Hay dos experiencias de usuario notables cuando se habla de autenticación. Cada una de ellas tiene sus propias características y son consecuencias de la naturaleza de la opción de autenticación que haya sido configurada.
El Single sign-on (SSO) es el concepto de autenticarse una sola vez y obtener acceso a todas las aplicaciones que comparten el mismo método y servidor de autenticación.
El Same sign-on es utilizar las mismas credenciales en cada una de las pantallas de inicio de sesión de las aplicaciones a las que debe acceder un usuario que comparten el servidor de autenticación.
Resumen de los métodos de autenticación
La siguiente tabla describe las características mas importantes de cada método de autenticación, desde la perspectiva de lo que se puede hacer con el desde Bizagi.
|
On-premises |
Single sign-on |
Same sign-on |
Cuándo usarlo |
Autenticación Federada SAML 2.0 |
|
|
|
Si tiene un IdP |
WS-Federation |
|
|
|
Si su IdP no soporta SAML 2.0 |
Autenticación Windows |
|
Depende de si está en la intranet o no |
|
Cuando no tiene un IdP |
OAuth2 - OpenID |
|
|
|
Cuando Autenticación Federada no es una opción |
LDAP |
|
|
|
Cuando la Autenticación Windows no es una opción |
Bizagi |
|
|
|
Si quiere que los usuarios y sus credenciales sean administrados independientemente en Bizagi |
Mixta |
|
Depende de los métodos seleccionados |
Depende de los métodos seleccionados |
Si su caso de uso tiene usuarios de negocio y externos |
Personalizada |
|
|
Depende de lo que configure |
Cuando no hay otra opción |
Importante
Por favor tenga en cuenta lo siguiente:
1.Es responsabilidad del cliente administrar las cuentas de los usuarios finales y sus accesos al Portal de Trabajo de Bizagi. Así como asegurar que las configuraciones que fuercen las políticas adecuadas de seguridad para dichas cuentas y sus respectivas contraseñas.
2.Con cualquier tipo de autenticación, el usuario por defecto domain\admon debe mantenerse habilitado, si bien no debe estar asignado a un usuario en específico, y no se le deben otorgar los derechos para usar los menúes y opciones del Portal de Trabajo. En vez de ello, se recomienda definir de manera explícita un usuario asignado como su administrador de negocio, que tenga los privilegios para usar las opciones del menú de administrador (por ejemplo, modificar los valores de entidades paramétricas, administrar sus usuarios, licencias, casos, etc.).
3.Al integrar un administrador de identidad, e independientemente del escogido, los clientes deben sincronizar las cuentas autorizadas para acceder al Portal de Trabajo de Bizagi.
Por sincronizar se debe entender la inserción o actualización de los identificadores primarios de las cuentas en Bizagi (dominio y usuario normalente, y correo electrónico).
Recuerde que las contraseñas no son almacenadas en Bizagi al integrar un administrador de identidad.
|
La sincronización de usuarios es una tarea que debe ser programada en Bizagi, conectándolo con su Directorio Activo (AD). Opciones alternativas a una sincronización AD/LDAP consideran invocar servicios web de Bizagi desde su lado (un "push"), o invocar desde Bizagi un servicio web de su lado para traer los usuarios (un "pull").
Hay maneras alternativas de popular la información de sus usuarios, refiérase a estos artículos para mayor información: •Synchronizing users via web services. •How to synchronize users from an excel file.
Si no va a sincronizar los usuarios todavía, puede probar que la autenticación funciona como se espera creando un usuario manualmente en el Portal de Trabajo para hacer validaciones. |
Autenticación para múltiples dominios
Si su proyecto usa más de un dominio, puede configurar la Autenticación múltiple, puede usar varios tipos de autenticación y dominios en su solución Bizagi. Un dominio se refiere a un grupo específico de usuarios que comparten parámetros comunes como su ubicación, área, corporación, entre otros.
Configuración
El Módulo de seguridad en Bizagi incluye un componente de Autenticación que tiene alta versatilidad en la administración y validación de los usuarios.
Puede escoger el tipo de autenticación de una serie de posibilidades que pueden ser usadas por su Portal de Trabajo, de acuerdo a las necesidades corporativas.
Con este módulo, la autenticación se puede configurar con Bizagi Studio; o similarmente a través del Management Console de Bizagi para ambientes en ejecución (en ambiente de pruebas o producción).
|
Cada vez que realiza cambios en la configuración de autenticación desde Bizagi Studio o la Consola de Administración, es necesario reinicar su servidor de aplicaciones o IIS. |
Autenticación en ejecución
Debido a medidas de seguridad estándar, el detalle de mensajes de error con respecto a intentos fallidos de autenticación no es mostrado en el Portal de Trabajo (al usuario final).
En un ambiente de producción, necesitará que se administrador del sistema revise los detalles del registro de eventos (log).
En un ambiente de desarrollo, puede activar una llave temporalmente para agilizar su implementación y pruebas.