Configuración para SAML2 en Bizagi

<< 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 SAML >

Configuración para SAML2 en Bizagi

Introducción

Bizagi ofrece integraciones con sistemas de administración de Identidad y Acceso que cumplan con el estándar del protocolo SAML 2.0.

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.

 

Prerrequisitos

Para configurar Azure AD, como con cualquier Proveedor de Identidad que soporte SAML 2.0, necesita:

 

Haber importado y sincronizado ya sus usuarios en Bizagi.

Cuando se integra cualquier Administrador de Identidad, es necesario sincronizar las cuentas autorizadas para que puedan acceder al Portal de Trabajo de Bizagi.

Sincronizar significa importar o actualizar sólo los identificadores primarios de la cuenta (el dominio más el nombre de usuario típicamente, y la dirección de correo electrónico).

Bizagi no almacena contraseñas cuando se integra un Administrador de Identidad.

 

note_pin

No puede tener dos o más usuarios con el mismo correo electrónico, porque el email se considera como parte del identificador principal.

 

Una vez que usted ha verificado en el Portal de Trabajo que ha habido al menos una importación inicial de sus usuarios en Bizagi, puede proceder:

 

125Users13

 

note_pin

En Bizagi, los identificadores únicos para los usuarios son el correo electrónico o la combinación de dominio y nombre de usuario. Recomendamos el uso del correo electrónico en su configuración de Azure como identificador único.

 

1. Generar certificados para firmar afirmaciones (obligatorio)

Este paso no está ligado a Bizagi ni restringido por ningún requerimiento especial de Bizagi (normalmente lo hace usted).

Si necesita alguna orientación o un ejemplo sobre este paso, consulte la sección Certificados para autenticación SAML 2.0.

 

Para continuar con estos pasos guiados, debe tener:

Un certificado para firmar afirmaciones (obligatorio) en formato de archivo .P12 o .PFX. Necesita la contraseña para el archivo de certificado, tal como la definió cuando exportó las claves pública y privada.

Un certificado para cifrar mensajes (opcional) en formato de archivo .P12 o .PFX. Necesita la contraseña para el archivo de certificado, tal como la definió cuando exportó las claves pública y privada.

 

note_pin

Deberá encargarse de la gestión de los certificados instalados (realizar un seguimiento de su fecha de caducidad y de otros aspectos de mantenimiento relevantes, como los cambios en los puntos finales de su Proveedor de Identidad).

 

 

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.

 

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

 

2.Configurar el proveedor de identidad en Bizagi Studio o la Consola de Administración

 

Si lo va a configurar desde el entorno de desarrollo, abra Bizagi Studio.

 

Busque el módulo de Seguridad y haga clic en la opción Autenticación que se encuentra debajo del elemento Seguridad.

Seleccione Autenticación federada en la lista desplegable del panel de la derecha y seleccione SAML v2.0 en el menú desplegable de la parte inferior derecha:

 

SAML_Bizagiparams1

 

En estas configuraciones, usted establecerá:

Permitir encripción de aserciones: Cuando Bizagi envía mensaje al IdP, se envían dos tipos de aserciones.

 -Solicitudes de autenticación: estas aserciones no contienen información sensible, por lo tanto no son encriptados por definición del estandard.

 -Solicitud de cierre de sesión. Estos mensajes si contienen información sensible, por lo tanto pueden ser encriptados. Si usted define esta propiedad como encendida, las solicitudes de cierre de sesión son encriptadas por Bizagi. Asegúrese de que su proveedor de identidad soporta recibir estas solicitudes de manera encriptada.

Por otro lado, Bizagi puede interpretar mensajes encriptados enviados desde el IdP, inclusive si esta propieda está apagada.

 

Okta no soporta recibir mensajes encriptados, por lo tanto esta opción debe estar apagada.

 

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 Portal de Trabajo).

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

 

La URL de metadata depende del IdP, aquí hay unos ejemplos:

 

Azure AD: https://login.microsoftonline.com/[Tenant]/federationmetadata/2007-06/federationmetadata.xml?appid=[applicationID]

 

note_pin

El applicationID corresponde al identificador que Azure asigna a la aplicación cuyos usuarios serán validados en el proceso de autenticación. Tenga en cuenta que este identificador puede consultarse solo después de registrar la aplicación. Para obtener más información, consulte Configuración SAML2 con Azure AD.

 

ADFS: https://[my_federateserver]/FederationMetadata/2007-06/FederationMetadata.xml

OKTA: https://[company].okta.com/app/[id]/sso/saml/metadata

 

note_pin

Puede dejar este parámetro en blanco en la configuración inicial o utilizar una URL ficticia. Después de configurar su IdP, puede registrar este parámetro.

 

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 incluye 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 Portal de Trabajo de Bizagi. Para Automation Service, 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 Automation Service, [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 cambiándole 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.

 

3 Descargar el archivo de metadata y subirlo en el proveedor de identidad

Antes de configurar Bizagi como proveedor de servicios en su proveedor de identidad, debe descargar un archivo que contenga los metadatos de la configuración SAML. Los proveedores de identidad generalmente requieren este archivo para definir configuraciones predefinidas.

 

Asegurese de subir en Certificado de firma y la Contraseña del certificado de firma.

Para descargar el archivo de metadata, Bizagi tiene los siguientes endpoints

 

Puede revisar el archivo de metadata buscando en:

https://[environment]-[project]-[company].bizagi.com/saml2/metadata.xml?mode=preview

 

Descargar el archivo ingresar la siguiente URL en su navegador

https://[environment]-[project]-[company].bizagi.com/saml2/metadata.xml?mode=attachment

 

 

note_pin

Con los certificados X509, un objeto de la llave  pública / privada temporal se almacena en el directorio de llaves de la máquina. Si obtiene un error de acceso denegado:

 

FederatedAuthentication_Error

 

Asegúrese de que el usuario del grupo de aplicaciones en el servidor IIS tenga permisos como network_services para escribir en esta carpeta C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. En su lugar, sugerimos utilizar la identidad del grupo de aplicaciones.

 

3. Configuración inicial en su proveedor de identidad

Primero, debe configurar el proveedor de identidad. Vea algunos ejemplos:

 

Azure AD

Azure AD B2C

ADFS

Okta

NetIQ

PingFederate

 

Al ir a las opciones 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.

 

Endpoints

Usted necesita registrar en su proveedor de identidad los siguientes endpoints:

 

Single Sign on URL: Registre la URL the su Portal de Trabajo seguido del sufijo /saml2/assertionConsumer.

Para Automation Service, la URL tiene este formato:

https://[environment]-[project]-[company].bizagi.com/saml2/assertionConsumer

Para proyectos on-premises , la URL tiene este formato:

https://[server]/[project]/saml2/assertionConsumer

 

Service Provider ID URI (también conocida como audience ID URI or Application ID URI: Registre la URL de si Portal de Trabajo como la definió en la configuración de autenticación de Bizagi Studio o la Consola de Administracion

Para Automation Service, la URL tiene este formato:

https://[environment]-[project]-[company].bizagi.com/

Para proyectos on-premises , la URL tiene este formato:

https://[server]/[project]/

 

Single Logout URL: Registre la URL the su Portal de Trabajo seguido del sufijo /saml2/logout.

Para Automation Service, la URL tiene este formato:

https://[environment]-[project]-[company].bizagi.com/saml2/logout

Para proyectos on-premises , la URL tiene este formato:

https://[server]/[project]/saml2/logout