Control de acceso y roles

El modelo de control de acceso de Mondrian le permite dividir su schema en roles. Un rol es un conjunto nombrado de grants y denegaciones que cubre todo el schema — desde qué cubos son visibles hasta qué miembros individuales un usuario puede ver. Los roles se definen directamente en el archivo de schema, y Saiku Cloud los aplica cuando establece una conexión en nombre de un usuario.

Definir un rol

Los elementos <Role> son hijos directos de <Schema>, colocados tras el último <Cube>. Aquí hay un ejemplo completo:

YAML

- name: "California manager"
  schema_grant:
    access: "none"
    cubes:
    - cube: "Sales"
      access: "all"
      dimensions:
      - dimension: "[Measures]"
        access: "all"
      hierarchies:
      - hierarchy: "[Store]"
        access: "custom"
        top_level: "[Store].[Store Country]"
        members:
        - member: "[Store].[USA].[CA]"
          access: "all"
        - member: "[Store].[USA].[CA].[Los Angeles]"
          access: "none"
      - hierarchy: "[Customers]"
        access: "custom"
        top_level: "[Customers].[State Province]"
        bottom_level: "[Customers].[City]"
        members:
        - member: "[Customers].[USA].[CA]"
          access: "all"
        - member: "[Customers].[USA].[CA].[Los Angeles]"
          access: "none"
      - hierarchy: "[Gender]"
        access: "none"

XML

<Role name="California manager">
  <SchemaGrant access="none">
    <CubeGrant cube="Sales" access="all">
      <DimensionGrant dimension="[Measures]" access="all"/>

      <HierarchyGrant hierarchy="[Store]" access="custom"
                      topLevel="[Store].[Store Country]">
        <MemberGrant member="[Store].[USA].[CA]" access="all"/>
        <MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>

      <HierarchyGrant hierarchy="[Customers]" access="custom"
                      topLevel="[Customers].[State Province]"
                      bottomLevel="[Customers].[City]">
        <MemberGrant member="[Customers].[USA].[CA]" access="all"/>
        <MemberGrant member="[Customers].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>

      <HierarchyGrant hierarchy="[Gender]" access="none"/>
    </CubeGrant>
  </SchemaGrant>
</Role>

Las secciones siguientes explican cada elemento en detalle.

---

<SchemaGrant>

<SchemaGrant> define el acceso por defecto al schema entero. Su atributo access puede ser:

Valor	Significado
all	El rol puede ver cada cubo y dimensión del schema.
all_dimensions	El rol puede ver todas las dimensiones pero aún necesita entradas explícitas de <CubeGrant> para acceder a los datos de cualquier cubo.
none	El rol no puede ver nada a menos que se le otorgue explícitamente.

En el ejemplo anterior, access="none" significa que el usuario solo puede navegar el cubo “Sales”, porque es el único explícitamente otorgado.

---

<CubeGrant>

<CubeGrant> controla el acceso a un cubo específico. Su atributo access puede ser:

Valor	Significado
all	Acceso total al cubo y a todas sus dimensiones y jerarquías.
custom	El acceso lo definen los elementos hijos <DimensionGrant> y <HierarchyGrant>.
none	El cubo se oculta al rol.

---

<DimensionGrant>

<DimensionGrant> controla el acceso a una dimensión completa dentro de un cubo. Su atributo access puede ser:

Valor	Significado
all	Todas las jerarquías hijas de esta dimensión son accesibles.
custom	Sin acceso heredado a jerarquías hijas — cada jerarquía debe otorgarse por separado usando <HierarchyGrant>.
none	La dimensión se oculta.

El atributo dimension toma el nombre único MDX de la dimensión (por ejemplo "[Measures]" o "[Store]").

---

<HierarchyGrant>

<HierarchyGrant> controla el acceso a una jerarquía, opcionalmente acotando los niveles y miembros visibles.

Atributo	Requerido	Descripción
hierarchy	sí	Nombre único MDX de la jerarquía, por ejemplo "[Store]".
access	sí	"all", "custom" o "none".
topLevel	no	Nombre único MDX del nivel visible más alto. Los miembros por encima de este nivel se ocultan.
bottomLevel	no	Nombre único MDX del nivel visible más bajo. Los miembros por debajo de este nivel se ocultan.
rollupPolicy	no	Cómo calcular totales cuando hay hijos ocultos. Consulte Política de rollup.

Valores de access

Valor	Significado
all	Cada miembro es visible.
none	La jerarquía se oculta al rol.
custom	La visibilidad la controla topLevel, bottomLevel y/o hijos <MemberGrant>.

---

<MemberGrant>

<MemberGrant> otorga o deniega acceso a un miembro específico y a todos sus hijos. Solo puede usar <MemberGrant> cuando el <HierarchyGrant> que lo contiene tiene access="custom".

Atributo	Requerido	Descripción
member	sí	Nombre único MDX del miembro, por ejemplo "[Store].[USA].[CA]".
access	sí	"all" o "none".

Reglas para grants de miembros

Los grants de miembros interactúan de una forma específica cuando varios grants aplican a la misma jerarquía:

1. Los miembros heredan el acceso de sus padres. Denegar acceso a California deniega automáticamente acceso a San Francisco.
2. Los grants dependen del orden. Si otorga acceso a USA, luego deniega Oregon, Oregon queda oculto. Si deniega Oregon primero y luego otorga USA, todo es visible. El orden importa.
3. Un miembro es visible si alguno de sus hijos es visible. Si deniega USA pero otorga California, verá USA y California — pero ningún otro estado. Nota: los totales para USA bajo la política full de rollup todavía reflejan todos los estados (consulte Política de rollup). Si hay un topLevel, solo se muestran los padres en o por debajo de ese nivel.
4. Los grants de miembros no sobrescriben topLevel y bottomLevel. Si topLevel="[Store].[Store State]" está definido y otorga California, todavía no puede ver el nivel USA.

Recorrido de ejemplo

Con el rol “California manager” del ejemplo de apertura, el usuario puede:

• Ver California y todas las ciudades de California excepto Los Angeles.
• Ver USA (porque California, un hijo visible, hace visible al padre), pero ningún otro país.
• No ver “All Stores” porque está por encima del topLevel de Store Country.
• No ver clientes fuera de la banda state-to-city (State Province hasta City), y no Los Angeles.
• No ver la jerarquía Gender en absoluto.

---

Seguridad de fila basada en predicado (<PredicateGrant>)

Los grants de miembros restringen qué miembros de dimensión puede ver un rol. A veces, en su lugar, necesita restringir las filas de hechos mismas por un valor de columna que rastrea al usuario solicitante — seguridad clásica multi-tenant a nivel de fila, o el access_filter de Looker. Para eso, Saiku añade un <PredicateGrant> (una extensión Saiku para Mondrian 4, issue #106): vincula un rol a un filtro sobre una columna de hecho real, con valor del parámetro de consulta de la conexión.

<Role name="Regional">
  <SchemaGrant access="all"/>
  <PredicateGrant measureGroup="Sales" column="region"
                  operator="eq" parameter="region"/>
</Role>

El backend Calcite inyecta el predicado como un filtro WHERE en cada carga de segmento del grupo de medidas nombrado, pre-agregación, así que los totales — no solo las filas hoja — están correctamente restringidos, y el resultado por rol se aísla en la caché de segmentos. Un parámetro no enlazado falla cerrado (cero filas), nunca sin restringir. operator es eq (igualdad) o in (pertenencia).

Nota

Esta es la contraparte de seguridad de fila para los grants de miembros, y está documentada en detalle — declaración, suministrar el valor en tiempo de conexión, el modelo de seguridad y el mapeo de access_filter de LookML — en la página de Parámetros de consulta y seguridad de fila. Los predicate grants requieren el backend de consulta Calcite (mondrian.backend=calcite, el predeterminado de Saiku).

---

Política de rollup

Una política de rollup determina qué valor muestra Mondrian para un miembro padre cuando el rol actual no puede ver todos sus hijos.

Política	Significado
full	El total del padre incluye todos los hijos, visibles o no. Es el valor por defecto.
partial	El total del padre incluye solo los hijos accesibles.
hidden	Si algún hijo es inaccesible, el total del padre se suprime.

Ejemplo: efecto de cada política

Suponga que un rol puede ver [USA].[CA] y [USA].[OR] pero no [USA].[WA], y ejecuta:

SELECT {[Measures].[Unit Sales]} ON COLUMNS,
       {[Store].[USA], [Store].[USA].Children} ON ROWS
FROM [Sales]

Full (por defecto) — el total [USA] incluye las 124 366 unidades de Washington:

Miembro	Unit Sales
[USA]	266,773
[USA].[CA]	74,748
[USA].[OR]	67,659

Partial — el total [USA] refleja solo CA y OR:

Miembro	Unit Sales
[USA]	142,407
[USA].[CA]	74,748
[USA].[OR]	67,659

Hidden — el total [USA] se suprime porque al menos un hijo es inaccesible:

Miembro	Unit Sales
[USA]	—
[USA].[CA]	74,748
[USA].[OR]	67,659

Especificar la política de rollup

El atributo rollupPolicy se coloca en <HierarchyGrant>. Puede aplicar políticas diferentes a jerarquías diferentes en el mismo rol:

YAML

- name: "South Pacific manager"
  schema_grant:
    access: "none"
    cubes:
    - cube: "Sales"
      access: "all"
      hierarchies:
      - hierarchy: "[Store]"
        access: "custom"
        top_level: "[Store].[Store Country]"
        rollup_policy: "partial"
        members:
        - member: "[Store].[USA].[CA]"
          access: "all"
        - member: "[Store].[USA].[CA].[Los Angeles]"
          access: "none"
      - hierarchy: "[Customers]"
        access: "custom"
        top_level: "[Customers].[State Province]"
        bottom_level: "[Customers].[City]"
        rollup_policy: "full"
        members:
        - member: "[Customers].[USA].[CA]"
          access: "all"
        - member: "[Customers].[USA].[CA].[Los Angeles]"
          access: "none"
      - hierarchy: "[Gender]"
        access: "none"

XML

<Role name="South Pacific manager">
  <SchemaGrant access="none">
    <CubeGrant cube="Sales" access="all">
      <HierarchyGrant hierarchy="[Store]" access="custom"
                      rollupPolicy="partial"
                      topLevel="[Store].[Store Country]">
        <MemberGrant member="[Store].[USA].[CA]" access="all"/>
        <MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>

      <HierarchyGrant hierarchy="[Customers]" access="custom"
                      rollupPolicy="full"
                      topLevel="[Customers].[State Province]"
                      bottomLevel="[Customers].[City]">
        <MemberGrant member="[Customers].[USA].[CA]" access="all"/>
        <MemberGrant member="[Customers].[USA].[CA].[Los Angeles]" access="none"/>
      </HierarchyGrant>

      <HierarchyGrant hierarchy="[Gender]" access="none"/>
    </CubeGrant>
  </SchemaGrant>
</Role>

---

Roles de unión

Un rol de unión combina los privilegios de dos o más roles existentes. El resultado tiene el acceso menos restrictivo entre todos sus roles constituyentes: el rol de unión puede ver cualquier objeto del schema que al menos un rol constituyente pueda ver, y su política de rollup para una jerarquía dada es la política menos restrictiva entre todos los constituyentes.

<Role name="Coastal manager">
  <Union>
    <RoleUsage roleName="California manager"/>
    <RoleUsage roleName="Eastern sales manager"/>
  </Union>
</Role>

Los roles constituyentes deben declararse antes en el archivo de schema. Pueden ser roles regulares, otros roles de unión o roles personalizados respaldados por clase. El rol de unión “Coastal manager” puede ver cualquier miembro accesible para cualquier constituyente, y también puede ver celdas en la intersección de miembros que solo un rol puede ver.

Precaución

Los roles de unión (<Union> / <RoleUsage>) aún no tienen equivalente YAML — el conversor de schema YAML no los hace round-trip, así que esta construcción solo se muestra en XML. Cree roles de unión directamente en XML, o componga los grants equivalentes en un único rol en YAML.

---

Definir el rol de una conexión

Un rol surte efecto cuando se asocia con una conexión. Por defecto, las conexiones tienen un rol sin restricciones que puede ver cada cubo en el schema. Hay dos formas de activar un rol específico:

En la cadena de conexión

Incluya la palabra clave Role en la cadena de conexión de Mondrian. Saiku Cloud establece esto en nombre de sus usuarios basándose en la configuración de su tenant:

Provider=mondrian; Role="California manager";
Jdbc=jdbc:postgresql://host/db; JdbcUser=user; JdbcPassword=pw;
Catalog=/WEB-INF/MySchema.mondrian.xml

Para activar varios roles a la vez (creando una unión ad hoc), separe los nombres con comas. Si un nombre de rol contiene una coma, escápela con una coma doble.

Programáticamente

Si está incrustando Mondrian directamente, llame a Connection.setRole(Role) tras abrir una conexión, o busque un rol nombrado con Schema.lookupRole(String).

---

Rol por defecto

Puede marcar un rol como predeterminado en su schema usando el atributo defaultRole en <Schema>. Cualquier conexión que no especifique explícitamente un rol usará este predeterminado:

<Schema name="FoodMart" defaultRole="California manager">
  ...
</Schema>

---

Roles en schemas YAML

Si crea su schema en formato YAML, los roles se declaran bajo la clave de nivel superior roles. Cada entrada mapea a un elemento <Role>. Consulte la referencia de schema YAML para la sintaxis completa de roles, incluyendo las claves schema_grant, cubes, hierarchies, members, rollup_policy, top_level y bottom_level.

Un ejemplo rápido:

roles:
  - name: "California manager"
    schema_grant:
      access: "none"
      cubes:
        - cube: "Sales"
          access: "all"
          hierarchies:
            - hierarchy: "[Store].[Stores]"
              access: "custom"
              top_level: "[Store].[Stores].[Store Country]"
              members:
                - member: "[Store].[Stores].[USA].[CA]"
                  access: "all"
                - member: "[Store].[Stores].[USA].[CA].[Los Angeles]"
                  access: "none"

  - name: "No HR Cube"
    schema_grant:
      access: "all"
      cubes:
        - cube: "HR"
          access: "none"

Consejo

Los roles se emiten al final del XML generado para que todas las referencias a cubos se resuelvan correctamente. Si edita el XML a mano, coloque los elementos <Role> tras el último <Cube>.

---

Adaptado de la guía del schema del proyecto Mondrian (EPL v1.0).