Saltar al contenido

Alcance en Jitterbit App Builder

Alcance es un propósito de regla que implementa Seguridad a Nivel de Fila (RLS) en App Builder, restringiendo qué filas de datos están disponibles para cada usuario. Puede evitar que un representante de ventas vea cuentas fuera de su territorio asignado, impedir que un empleado vea datos fuera de su región o división, o evitar que un cliente en una aplicación multiinquilino vea los registros de otro.

Muchos Sistemas de Gestión de Bases de Datos Relacionales (RDBMS) ofrecen soporte nativo para seguridad a nivel de fila, pero Alcance no se construye como un envoltorio alrededor de ese soporte. En su lugar, se implementa directamente por el motor de negocio de App Builder, por lo que se comporta de la misma manera sin importar qué base de datos esté debajo.

Esta página define cómo funciona la característica, incluyendo pasos para crear y registrar una regla de Alcance. Luego, hay mejores prácticas, algunos ejemplos prácticos y una lista de las limitaciones actuales de la característica.

Un tutorial completo que construye una regla de Alcance con datos de demostración y la registra en un objeto de negocio está disponible en la sección Alcance de Introducción a App Builder - Apéndice D: Seguridad.

Definición

Para usar la característica de Alcance, son necesarios tres pasos: crear una regla de Alcance, establecer qué token devolverá y registrar esa regla contra un objeto de datos.

  • Crear una regla de Alcance: Una regla de Alcance es una regla de negocio creada con el propósito de Alcance. Como otros tipos de reglas, tales como Predeterminado o Validación, las reglas de Alcance son fundamentalmente consultas mvSQL bajo el capó. El trabajo de una regla de Alcance es determinar qué segmentos de datos puede acceder un usuario determinado, generalmente llamando a las funciones mvSQL who() o session() para vincular ese acceso nuevamente a quién está actualmente conectado. Consulta cómo Crear una regla de Alcance a continuación.

  • Establecer el token de la regla de Alcance: Cada regla de Alcance selecciona exactamente una columna para actuar como su Token de Alcance. Esto se establece a través del campo Tipo de Uso de Columna de esa columna. Cada fila devuelta por la regla es un segmento de datos al que el usuario actual puede acceder. Si no se devuelven filas, significa que el usuario no tiene acceso en absoluto. Consulta cómo Establecer el token de la regla de Alcance a continuación.

    Los tokens generalmente identifican un grupo amplio (por ejemplo, una región geográfica), en lugar de un único registro, porque verificar el acceso segmento por segmento es mucho más económico que fila por fila. El token de un gerente de ventas podría ser el ID de su región, permitiéndole extraer reportes para cada cliente en ese territorio en lugar de solo uno. Las aplicaciones multiinquilino son una excepción común: allí, el token puede apuntar a la fila del cliente del usuario, ya que el cliente mismo es el segmento que se está restringiendo.

    El token no necesita vivir en la tabla de destino de la propia regla de Alcance. Se puede extraer desde más arriba en una cadena de relaciones, a través de una unión, siempre que siga identificando un segmento al que el objeto de datos restringido pueda vincularse.

  • Registrar una regla de Alcance contra un objeto de datos: Una regla de Alcance no tiene efecto hasta que se registra en un objeto de datos. Un objeto de datos puede tener más de un registro, en cuyo caso un usuario solo ve filas que satisfacen todos ellos a la vez. Consulta Registrar una regla de Alcance a continuación para obtener instrucciones.

Crear una regla de Alcance

Para construir una nueva regla de Alcance desde cero:

  1. En App Workbench > Reglas, haz clic en + Regla. Se abre el Generador de Reglas.

  2. Siguiendo las convenciones de nomenclatura de App Builder, nombra la regla usando el patrón NombreTabla (Alcance) Descriptor.

  3. En el campo Purpose, desplázate hacia abajo hasta Reach bajo Edge Case y selecciónalo.

  4. En el campo Target, selecciona la tabla que la regla debe consultar.

  5. Haz clic en Create.

Establece el token de la regla Reach

Una vez que hayas creado una regla Reach, necesitas establecer su token. El token identifica los segmentos de datos que se muestran a un usuario.

  1. Accede al Rule Builder de la regla Reach.

  2. En la pestaña Where, añade una cláusula que vincule el usuario actual a los datos a los que puede acceder, típicamente con la función who(). Si la tabla no tiene ya una columna que vincule una fila a un usuario de App Builder, añade una, junto con un control para que se pueda establecer desde la interfaz.

  3. En la pestaña Columns, añade la columna que identifica el segmento accesible, luego haz doble clic en ella y establece su Column Usage Type en Reach Token.

  4. Haz clic en Results en el panel Rule para confirmar que la regla devuelve los segmentos que esperas.

Registra una regla Reach

Una vez que la regla existe, adjúntala a cualquier objeto de datos que desees que restrinja:

  1. Navega al panel Rule del objeto de negocio que deseas restringir.

    Nota

    Una regla Reach solo se puede registrar en un objeto de negocio construido sobre la misma tabla física o vista que tiene como destino, no directamente en una tabla. Consulta Best practices and recommendations a continuación para ver un patrón que aplica una regla Reach a una tabla completa.

  2. Haz clic en More > Edge Case. Se abre el diálogo Edge Case Settings.

  3. Haz clic en Reach. Se abre el diálogo Reach Registration.

  4. Haz clic en Create. El diálogo ahora muestra un formulario con los siguientes campos:

    Reach Registration

    • Bajo Reach Information:

      • Rule: Selecciona la regla Reach que creaste.

      • Binding Column: Selecciona la columna que corresponde al Reach Token.

      • Role: (Opcional) Selecciona el rol al que debe aplicarse la restricción, o déjalo en blanco para aplicar la restricción a todos mientras confirmas que la regla se comporta como se espera. Consulta Best practices and recommendations a continuación.

    • Bajo Position:

      • Index: (Opcional) Introduce un número para establecer el orden de esta regla en relación con cualquier otra regla Reach registrada en el mismo objeto.

      • Active: Déjalo marcado para aplicar la regla, o desmárcalo para desactivar la restricción sin eliminar el registro.

      • Technical Help: (Opcional) Introduce información descriptiva para ayudar a otros desarrolladores.

  5. Haz clic en Save.

Actualiza la página para ver la restricción en efecto.

Nota

Reach se aplica mediante el evento Filter en sí, no por la interfaz, por lo que la restricción se mantiene incluso para un usuario que navega directamente a la URL de un registro restringido en lugar de encontrarlo a través de una lista o búsqueda.

Una vez que un objeto de negocio tiene al menos una regla Reach registrada, también aparece un botón Reach directamente en su panel Rule, junto a Events y Roles, con una insignia que muestra cuántas reglas Reach están registradas. Haz clic en él para ver, editar o añadir más registros sin pasar nuevamente por More > Edge Case.

Mejores prácticas y recomendaciones

Las siguientes mejores prácticas pueden ayudarte a ahorrar tiempo al crear reglas Reach:

  • Cuando registres una nueva regla Reach, deja el campo Role en blanco hasta que hayas confirmado que funciona. Una vez verificada, vincúlala al rol que está destinada a restringir, para que los roles administrativos, como Superuser, mantengan acceso completo.

  • Registra la regla en cada objeto de negocio que expone los datos que estás restringiendo. Un registro solo afecta al objeto específico al que está adjunto, no a todas las otras reglas construidas sobre la misma tabla subyacente, por lo que restringir Customer (Source) no tiene efecto en un objeto Customer (List) separado construido sobre la misma tabla Customer a menos que también registres la regla allí.

  • Favorece un token que identifique un segmento de filas, como una región o tipo de cuenta, en lugar de uno que identifique filas individuales. Una regla con ese alcance tan amplio tiene muchas menos filas que verificar en cada evento Filter.

  • Para ver qué reglas en una aplicación ya tienen Reach aplicado, ve a App Workbench > Rules y verifica la columna Reach, o haz clic en la pestaña With Reach para filtrar la cuadrícula solo a esas reglas.

  • Para ver qué páginas están restringidas por Reach para un rol determinado, ve a App Workbench > Roles y selecciona ese rol. Su diagrama de página marca cada página restringida con un icono de mano .

  • Dado que una regla Reach no se puede registrar directamente en una tabla, crea un objeto de negocio que seleccione cada columna de la tabla, siguiendo el patrón de nomenclatura TableName (With Reach), y registra la regla Reach en ese lugar. Luego, dondequiera que otra regla haría referencia a la tabla subyacente, haz referencia a TableName (With Reach) en su lugar: como Reach se hereda de los objetos que una consulta referencia, esto aplica la restricción en todas partes donde se use ese objeto de negocio, sin necesidad de registrarlo una y otra vez.

Ejemplos

Acceso basado en región

Imagina una aplicación con el siguiente esquema de tabla:

Tabla Clave principal Relaciones
Region RegionId
Customer CustomerId RegionId, clave externa a la tabla Region.
Employee EmployeeId RegionId, clave externa a la tabla Region.
UserId, referencia a usuario de App Builder.

En este modelo, los empleados y clientes pertenecen a una región, y cada empleado está vinculado a un usuario de App Builder.

La siguiente regla restringe a los usuarios para que solo vean clientes en su propia región:

SELECT RegionId
FROM Employee
WHERE UserId = who('userid')

Dado que esta regla se dirige a la tabla Customer, se puede registrar en el objeto de datos Customer (Source), y desde allí se aplica a cada panel construido sobre ese objeto de datos.

Sin embargo, las reglas Reach generalmente no deberían aplicarse a todos. En su lugar, úsalas junto con seguridad basada en roles. Por ejemplo, supongamos que la fuente de datos define un rol Administrator que puede ver cada cliente, y un rol Sales que solo debería ver clientes en su propia región. Registrar la regla contra el rol Sales mantiene a los administradores sin afectar, mientras que los usuarios de Sales solo ven los clientes de su propia región.

Combinación de múltiples atributos con una tabla puente

Un Reach Token no tiene que provenir de una única relación directa. Cuando el acceso depende de una combinación de atributos, por ejemplo, un empleado que solo puede ver clientes en regiones específicas y niveles de cliente específicos, una tabla puente puede resolver esa combinación hasta los registros individuales que un usuario puede ver.

Agrega una tabla puente, como EmployeeAccess, con una columna EmployeeID, RegionID y CustomerTierID, almacenando una fila para cada combinación de región y nivel que un empleado puede acceder. La siguiente regla se une a través de esa tabla para devolver cada CustomerID que el usuario actual puede ver:

SELECT c.CustomerID
FROM EmployeeAccess ea
JOIN Employee e ON e.EmployeeID = ea.EmployeeID
JOIN Customer c ON c.RegionID = ea.RegionID AND c.CustomerTierID = ea.CustomerTierID
WHERE e.UserID = who('userid')

Aquí, CustomerID es el Reach Token: en lugar de identificar un segmento amplio, la regla resuelve la intersección de cada región y nivel al que el usuario tiene acceso hasta los registros de cliente específicos que coinciden. Este patrón maneja relaciones muchos-a-muchos, como empleados asignados a más de una región o nivel, y excepciones por usuario que un token de columna única más simple no puede expresar.

Implementación

Cada regla de App Builder se conecta a un conjunto compartido de eventos intrínsecos, y Reach específicamente se vincula al evento Filter, el responsable de recuperar filas. Por eso, Reach solo tiene efecto dondequiera que un evento Filter realmente se ejecute:

  • Paneles: paneles Grid y Form, paneles Chart y Calendar, y similares.
  • Controles: controles List y Radio.
  • CRUD: solo reglas CRUD de negocio, no reglas CRUD de acceso directo a base de datos, ya que estas omiten completamente el motor de negocio.

Limitaciones

Se aplican las siguientes restricciones al implementar Reach:

  • Reach solo funciona con fuentes de datos RDBMS.
  • Reach no admite operaciones multiplataforma: la regla y el objeto de datos al que se registra deben pertenecer a la misma fuente de datos.
  • Reach no tiene efecto en operaciones CRUD de acceso directo a base de datos, ya que estas omiten el motor de negocio que lo aplica.
  • Una regla Reach solo puede tener una columna Reach Token, por lo que un objeto de datos se vincula a través de una sola columna, a diferencia de otros tipos de reglas que permiten vinculación en múltiples columnas.
  • Reach actualmente no se admite junto con App Builder Connector.
  • Copiar un objeto de datos no transfiere sus registros Reach, igual que ocurre con las reglas Default, Validation y Action.