Privilegios y permisos en Jitterbit App Builder

Descripción general

El modelo de autorización de App Builder se basa en dos conceptos relacionados pero distintos. Un privilegio determina si un grupo puede acceder a una aplicación o fuente de datos, mientras que un permiso determina qué puede hacer realmente con los datos una vez dentro. El acceso de cada usuario es simplemente la suma de los privilegios y permisos otorgados a los grupos a los que pertenece.

Esta página explica ambas partes del modelo:

• Privilegios: Aprende cómo los administradores otorgan a un grupo acceso a una aplicación o fuente de datos, y cómo se relaciona ese acceso entre los dos.
• Permisos: Aprende cómo los roles otorgan acciones específicas sobre datos, y cómo esto a su vez determina qué páginas, enlaces de menú y controles de página puede ver un usuario.

Privilegios

Un privilegio es una concesión de sí o no que controla si un grupo tiene acceso a una aplicación o fuente de datos específica. Los administradores otorgan privilegios directamente a grupos, nunca a usuarios individuales, por lo que todos los miembros de un grupo comparten los privilegios que tiene el grupo. Esta sección cubre cómo funcionan los privilegios para grupos en general, y la relación específica entre el privilegio de una aplicación y los privilegios de las fuentes de datos que utiliza.

Grupos y privilegios

Los grupos organizan usuarios para que los administradores puedan gestionar su acceso colectivamente, en lugar de hacerlo usuario por usuario. Para dar a un grupo acceso a parte de App Builder, un administrador de seguridad le otorga privilegio a una aplicación o fuente de datos específica, siguiendo los pasos en Otorgar a un grupo acceso a una aplicación o fuente de datos.

Otorgar a un grupo privilegio a una aplicación normalmente extiende ese privilegio a las fuentes de datos que la aplicación utiliza. Esta extensión solo fluye en una dirección. Consulta Autorización de aplicaciones para conocer las excepciones a esta regla.

Autorización de aplicaciones

Una aplicación típicamente utiliza una o más fuentes de datos para almacenar y recuperar sus registros. Cuando un administrador de seguridad otorga a un grupo privilegio a una aplicación, App Builder extiende automáticamente ese privilegio a todas las fuentes de datos que la aplicación referencia, por lo que el grupo no necesita una segunda concesión separada para usar la aplicación normalmente.

Lo contrario no es cierto: otorgar a un grupo privilegio a una fuente de datos no le otorga privilegio a ninguna aplicación que use esa fuente de datos. El privilegio a una fuente de datos solo permite que un grupo trabaje con esa fuente de datos directamente, por ejemplo a través de un reporte o una integración, no a través de ninguna aplicación en particular.

Por ejemplo, supongamos que una fuente de datos customer es utilizada por dos aplicaciones diferentes, Customer Reports y Customer Lookup. Un grupo con privilegio a Customer Reports puede usar la fuente de datos customer a través de esa aplicación, pero el mismo grupo no puede abrir Customer Lookup a menos que se le otorgue privilegio a esa aplicación por separado, aunque ambas aplicaciones dependan de los mismos datos.

Permisos

Una vez que un grupo tiene privilegio en una fuente de datos, los permisos determinan exactamente qué pueden hacer sus miembros con los objetos de datos en ella, como consultar, insertar, actualizar o eliminar registros. Los permisos se otorgan a través de roles, y App Builder también los utiliza para decidir qué páginas, enlaces de menú y controles de página puede ver realmente un usuario. Esta sección cubre cómo funcionan los roles y permisos, y cómo moldean la experiencia del usuario en las páginas de una aplicación.

Autorización de fuente de datos

No todas las fuentes de datos necesitan el mismo nivel de granularidad. Una fuente de datos se asegura utilizando uno de dos modelos de autorización, dependiendo de si define algún rol:

Roles y permisos

Un rol es una combinación de permisos definidos en una fuente de datos, como Contributor o Viewer. Para fuentes de datos que utilizan autorización basada en roles, un rol es cómo se otorgan realmente los permisos: un administrador de seguridad agrega un grupo a uno o más roles, y cada miembro de ese grupo recibe todos los permisos que incluyen esos roles.

Los permisos en sí son la unidad más específica de control de acceso en App Builder. Cada uno otorga un único tipo de acción en un objeto de datos:

Un único rol puede combinar varios de estos permisos para coincidir con cómo un grupo de usuarios debe trabajar con los datos. Por ejemplo, un rol Contributor podría otorgar permisos de Insertar y Actualizar para que sus miembros puedan agregar y editar registros, mientras que un rol Viewer podría otorgar solo permiso de Lectura para que sus miembros puedan ver pero no tocar.

Autorización de página

Los usuarios están autorizados a ver e interactuar con páginas específicas según su acceso a objetos de datos. Esto es porque App Builder no asegura las páginas directamente; en su lugar, asegura los objetos de datos en los que se construye una página, y deriva el acceso del usuario a la página misma a partir de sus permisos a esos objetos. Existen tipos de paneles (como Grid, Form y Chart) y controles (como List) que están vinculados a objetos de datos, y por lo tanto están sujetos a esta verificación de permiso subyacente.

Un usuario tiene permiso en una página si y solo si tiene acceso de Lectura a cada objeto de datos que la página utiliza. Esta regla se aplica incluso a una página construida directamente en una fuente de datos, como una página de carga de archivos construida en un sistema de archivos local: el grupo del usuario necesita privilegio explícito en esa fuente de datos, separado de cualquier privilegio que tenga a través de una aplicación, antes de que la página sea accesible.

Si un usuario solicita una página para la cual no tiene permiso, recibe un error de "Acceso denegado". En la práctica, esto es poco común, ya que App Builder oculta o desactiva los enlaces y entradas de menú a páginas a las que un usuario no puede acceder en primer lugar; principalmente ocurre si la seguridad está mal configurada, o si un usuario navega directamente a la URL de una página, por ejemplo, haciendo clic en un enlace antiguo en un correo electrónico.

App Builder ajusta los enlaces de menú, los enlaces de página y los controles de página según los permisos de un usuario.

Enlaces de menú

Al construir enlaces de menú, App Builder verifica si el usuario tiene acceso de Lectura a la página de destino de cada enlace. Si es así, el enlace aparece en el menú; de lo contrario, App Builder lo oculta, por lo que los usuarios nunca ven entradas de menú para páginas que no pueden abrir.

Enlaces de página

De manera similar, al renderizar una página, App Builder verifica si el usuario tiene acceso de Lectura a la página de destino de cada enlace de página incrustado. Si es así, la página se renderiza según lo diseñado. De lo contrario, App Builder ajusta la página de la siguiente manera:

• Oculta el icono de enlace del panel Grid (chevron o popup) y desactiva su acción de doble clic.
• Oculta las columnas del panel Grid definidas por controles que no están vinculados a datos (como Botones).
• Renderiza los controles vinculados a datos dentro de paneles Grid o Form (como controles de Texto o Lista) como no clickeables.

Controles de página

Más allá de simplemente ocultar un enlace, App Builder también oculta o desactiva los controles específicos que ofrece una página, según los permisos que el grupo del usuario tenga para el objeto de datos subyacente: