De

<keywords content="keywords"> seguridad, privado, privados, público, publico, públicos, publicos, casos cerrados, información cerrada, información restringida, compartir información, información pública, información publica, informacion publica, permitir acceso, restringir acceso, restringir casos </keywords>

Seguridad por Caso

Existen compañías en las cuales el manejo de la información es un tema delicado que requiere de un control especial para limitar la exposición de la información a ciertos usuarios. Por ello se requiere poder definir la autorización del acceso a la información en el portal de trabajo, indicando qué usuarios tienen permisos sobre un caso y cuáles no están autorizados para ver información privilegiada.

En un escenario sin personalización de la seguridad, cualquier usuario puede buscar un caso y en la tabla de resultados puede acceder a toda su información relacionada. Sin embargo esta información puede ser confidencial y requeriría ser restringida para que sólo algunos usuarios pudiesen verla y estudiarla.

Para proveer la autorización de los casos de acuerdo a las necesidades de cada proyecto, en Bizagi se identificar dos tipos de usuarios: - Usuarios sin privilegios: no pueden ver ninguna información del caso. - Usuarios con privilegios: pueden ver toda la información de un caso.

Los usuarios con privilegios serán:

• Aquellos que hayan trabajado en el caso
• El creador del caso.
• Los usuarios que hayan estado asignados. El método de asignación a Todos hará que todos los usuarios que puedan tomar un caso queden automáticamente incluidos en la lista de usuarios privilegiados.

• Usuarios adicionados por medio de una expresión que les permita el acceso.

La seguridad debe ser definida a nivel de proceso desde la vista de Módulos. Los procesos pueden tener tres posibles niveles de seguridad que se aplicará a cada uno de los casos creados.

• Público: cualquier usuario puede buscarlo y ver toda su información.
• Privado: sólo tienen acceso a él los usuarios privilegiados.
• Como el padre (aplica para los subprocesos): la seguridad será compartida entre el caso padre y el hijo (o subproceso). Si el caso padre tiene seguridad Privada todas las personas que tengan privilegios sobre el caso padre podrán observar el caso hijo y al contrario. Si el caso padre tiene seguridad pública, todos los casos del padre y del hijo podrán ser vistos por todos los usuarios.

Si el sub-proceso tiene seguridad Como el padre y puede radicarse independiente, sus casos serán Privados.

Caso Privado

Seguridad Como el Padre

Los usuarios delegados podrán ver los casos que se han asignado a ellos en su lista de pendientes. Sin embargo si no hacen parte de la lista de Usuarios con privilegios, no podrán buscarlos a través del motor de consultas.

Escenarios de la seguridad por caso

En el portal de trabajo de Bizagi es posible acceder a los casos por varios lugares: 1. Búsqueda por número de caso o por Búsqueda

2. Carpetas Inteligentes

3. Carpetas Bizagi

4. Consultas

5. Lista de Pendientes

Para los cuatro primeros escenarios aplicará la seguridad por caso. Es decir, si un usuario hace parte de los usuarios privilegiados tendrá acceso a la información de caso que se encuentre por cualquiera de esos medios. La lista de pendientes NO TIENE seguridad por caso. Si un usuario tiene asignado un caso o ha sido delegado, el caso SIEMPRE aparecerá en su lista de pendientes y podrá acceder a él y a toda su información.

La seguridad debe ser definida en el desarrollo del proyecto. No es posible configurarlo en producción porque la seguridad está atada a toda la vida del caso por lo tanto no es posible incluirla en la mitad de un caso existente. Si se requiere hacer cambios a la seguridad de los casos en producción, se deben hacer en ambiente de desarrollo y luego hacer un deployment.

Administrador de Negocio o súper usuario

La seguridad por caso tiene un rol que está siempre por defecto disponible para todos los usuarios, llamado BA Business Administrator. Cualquier usuario que esté vinculado a este role podrá buscar cualquier caso sin restricciones. Es decir siempre será Privilegiados en todos los procesos

Expresiones para permitir o restringir acceso

Bizagi proporciona un conjunto de funciones que permiten adicionar o remover usuarios de la lista de personas con acceso a un caso abierto determinado, por medio de Expresiones.

Las funciones permiten:

• Adicionar UN usuario
• Adicionar una lista de usuarios
• Remover UN usuario
• Remover una lista usuarios

Funciones para Seguridad por caso

• CHelper.GrantCaseAccess(int idCase, int idUser): agrega el usuario a la lista de usuarios privilegiados
• CHelper.GrantCaseAccessToUsers (int idCase, Arry Users): agrega varios usuarios a la lista de privilegiados
• CHelper.RevokeCaseAccess(int idCase, int idUser): Elimina un usuario de la lista de privilegiados
• CHelper.RevokeCaseAccessToUsers (int idCase, Array Users): Elimina varios usuarios de la lista de privilegiados

Las funciones utilizan dos parámetros: el identificador único del caso y el identificador de los usuarios. Cuando es un solo usuario se recibe el entero del identificador del usuario. Cuando son varios usuarios se recibe un arreglo de identificadores de usuarios. Los identificadores son enteros que se crean automáticamente en Bizagi en cada registro. Por lo tanto cada caso tiene su identificador único, al igual que cada usuario. NUNCA Y POR NINGÚN MOTIVO se debe escribir en una expresión el identificador del usuario dejándolo fijo. Para conseguir los identificadores Bizagi proporciona una serie de métodos que permiten consultarlos. Por ejemplo, el método CHelper.getUsersForRole(int idRole) retorna un arreglo con los ids de los usuarios que pertenecen a un role determinado.

Para acceder al identificador de los casos se recomiendan estas funciones:

• Me.Case.Id, retorne el id del caso en el que se está actualmente.
• CHelper.getSiblingProcessesId (Me, iWfClassId): devuelve un arreglo de id de casos, de sub-procesos creados desde el mismo caso padre.
• CHelper.getSubProcessesId (Me): devuelve un arreglo de casos, de sub-procesos del caso padre actual.

Para más información sobre las funciones de obtención de identificadores de caso y usuarios visite CHelper

Ejemplo con expresiones

En un proceso de Solicitud de Compras se desea restringir la información de forma que sólo puedan acceder a los casos creados el usuario creador y su jefe. De acuerdo a lo explicado anteriormente, los usuarios que sean asignados durante el proceso del caso también tendrán acceso. El usuario creador, por definición, automáticamente será adicionado a la lista de usuarios con privilegios. Sin embargo, el jefe del usuario debe ser agregado por medio de una regla para que también pueda tener acceso al caso desde la primera actividad. Para lograr lo anterior se debe configurar el proceso para que tenga Seguridad por casos, y luego agregar una expresión que incluya al jefe del creador como usuario privilegiado. 1. En la vista de Módulos ingrese a las propiedades del proceso dando clic sobre su versión.

2. Seleccione la opción Casos privados (Private cases) para restringir el acceso de los casos y de clic en OK.

3. En el paso número 4 (cuatro) del asistente de procesos, vaya a Acciones de la Actividad (Activity Actions) para crear una expresión al entrar en la actividad de registro. La regla debe agregar a la lista de usuarios privilegiados al jefe del usuario que crea la solicitud.

En el siguiente video usted podrá ver cómo funcionaría en el Portal de Trabajo el ejemplo anterior. Se tienen tres usuarios. El primero CreatorUser será el creador del caso. El segundo, Boss, será el jefe. Finalmente el usuario llamado RestrictedUser será un usuario cualquiera que debe ser restringido. El usuario que crea el caso es adicionado a los usuarios privilegiados automáticamente. Hemos configurado previamente al usuario Boss para que sea el jefe del usuario creador. Un usuario adicional llamado RestrictedUser no podrá encontrar ni ver el caso que el Creador registre.

<videoflash>4lrco0126oU|640|505|</videoflash>

Seguridad Compartida con Sub-procesos

Los sub-procesos se pueden crear con Seguridad Como el Padre para que los usuarios que tengan privilegios sobre el caso padre tengan también sobre el hijo (sub-proceso) y viceversa. En el proceso de Solicitud de Compras utilizado anteriormente, una vez el jefe aprueba la solicitud se abre un sub-proceso de Cotizaciones. La persona encargada de hacer las cotizaciones, llamada usuario Quotations será asignada. Dado que es un usuario asignado podrá ver el caso del sub-proceso y su información en su bandeja de Pendientes. El usuario Quotations podrá ver su actividad pendiente en la lista de pendientes Y ADEMÁS tendrá privilegios sobre el caso padre. 1. En la vista de Módulos ingrese a las propiedades del proceso dando clic sobre su versión.

2. En la ventana de Propiedades seleccione la seguridad Como el Padre.

Con esta información los usuarios privilegiados del sub-proceso podrán tener acceso a toda su información y a la información del caso padre.

Seguridad Privada con Sub-procesos

Los sub-procesos que no tengan seguridad Como el Padre se comportan como los demás procesos. Públicos o Privados. En el caso de que sean privados los usuarios con privilegios sobre el sub-proceso NO tendrán privilegios sobre el caso padre. De la misma manera los usuarios con privilegios sobre el padre no tendrán privilegios sobre el sub-proceso. En el proceso de Solicitud de Compras utilizado anteriormente, una vez el jefe aprueba la solicitud se abre un sub-proceso de Cotizaciones. La persona encargada de hacer las cotizaciones, llamada usuario Quotations será asignada. Dado que es un usuario asignado podrá ver el caso del sub-proceso y su información en su bandeja de Pendientes. Como el sub-proceso NO tiene seguridad Como el padre, el usuario Quotations podrá ver su actividad pendiente en la lista de pendientes. Sin embargo NO tendrá privilegios sobre el caso padre.

Sin embargo el usuario Quotations NO podrá acceder a la información del caso padre Solicitud de Compras. Por esta razón Bizagi mostrará un mensaje informando que no tiene permisos.

Adicionar un usuario privilegiado con una expresión

En un proceso de Solicitud de Compras se desea restringir la información de forma que sólo puedan acceder a los casos creados los usuarios privilegiados (creador y asignados) y adicionalmente el Vicepresidente Comercial, quien no tiene asignaciones en dichos casos. Por lo anterior es necesario añadir al usuario vicepresidente a los usuarios privilegiados utilizando una expresión. Para ello, creamos una tabla paramétrica en donde guardaremos el Usuario Vicepresidente Comercial, de forma que podamos acceder fácilmente al identificador del usuario y que éste pueda ser administrado en caso de que cambie.

En el paso número 4 (cuatro) del asistente de procesos, vaya a Acciones de la Actividad (Activity Actions) para crear una expresión al entrar en la actividad de registro.

La expresión agrega a la lista de usuarios privilegiados al Vicepresidente. Se encuentra el registro del Vicepresidente en la tabla paramétrica creada, y se guarda su id en una variable. Luego, esta variable es registrada en la función que adiciona a los usuarios privilegiados.

Ejemplo para adicionar varios usuarios con una expresión

En un proceso de Solicitud de Compras se desea restringir la información de forma que sólo puedan acceder a los casos creados los usuarios privilegiados (creador y asignados) y adicionalmente el Vicepresidente Comercial y el Presidente. Estos dos usuarios no tienen asignaciones en dichos casos. Por lo anterior es necesario añadirlos e a los usuarios privilegiados utilizando una expresión. Para ello, creamos una tabla paramétrica en donde guardaremos los dos usuarios: Vicepresidente Comercial y Presidente, de forma que podamos acceder fácilmente a sus identificadores y puedan ser administrados en caso de que cambien.

En el paso número 4 (cuatro) del asistente de procesos, vaya a Acciones de la Actividad (Activity Actions) para crear una expresión al entrar en la actividad de registro.

La siguiente expresión agrega a la lista de usuarios privilegiados al Vicepresidente y al Presidente. Se encuentran todos los registros de la tabla paramétrica y se guardan los identificadores en una variable. Luego, esta variable es registrada en la función que adiciona a los usuarios privilegiados.

Administrar los permisos de acceso por SOA

Se puede permitir el acceso a casos de manera que se incluya un usuario dentro de los usuarios privilegiados de manera dinámica utilizando la capa SOA. Para ello, se enviará el dato del nombre de usuario y el dominio a través de una interfaz, y ésta adicionará automáticamente el usuario a la lista de privilegiados. Los nombres de usuario y dominios deben ser conocidos de antemano y deben ser enviados desde un sistema externo para que esta opción de adición sea usada.

Ejemplo para adicionar usuarios privilegiados por SOA

Para el proceso de Solicitud de Compras se desea permitir el acceso al usuario Vicepresidente Comercial ("VicepresidenteComercial") para que pueda ver la información de un caso. Asumiendo que éste caso se encuentra cerrado y se sabe que es el número 300, se opta por otorgar el privilegio desde una aplicación externa, invocando servicios web a través de la capa SOA de Bizagi. El método de los servicios web que debe ser invocado para otorgar acceso a usuarios es grantCaseAccess disponible en WorkflowEngineSOA.asmx. El XML de entrada, para la invocación de este método para el ejemplo mencionado se muestra a continuación:

Es posible otorgar acceso a más de un usuario para el caso, y para más de un caso por invocación del servicio web. Para ver un ejemplo sobre esto, revisar el siguiente ejemplo.

Ejemplo para restringir usuarios por SOA

Para el proceso de Solicitud de Compras se desea restringir los accesos de la siguiente manera:

• El usuario OperadorComercial2 no debe tener acceso al caso 300.
• El usuario OperadorComercial1 no debe tener acceso al caso 301.
• El usuario OperadorComercial1 no debe tener acceso al caso 302.
• El usuario VicepresidenteComercial no debe tener acceso al caso 302.

Asumiendo que éste caso se encuentre cerrado, se opta por otorgar el privilegio desde una aplicación externa, invocando servicios web a través de la capa SOA de Bizagi. El método de los servicios web que debe ser invocado para otorgar acceso a usuarios es revokeCaseAccess disponible en WorkflowEngineSOA.asmx. El XML de entrada, para la invocación de este método para contemplar los 4 cambios mencionados anteriormente se muestra a continuación:

Temas relacionados

El proceso de Solicitud de Compra de los ejemplos dados puede ser descargado gratuitamente de nuestro Process Central.

<comments/>