Actualización a 16 de agosto de 2017. Como puede observarse en el este enlace, finalmente se ha incorporado esta característica a la propia creación del token de autentificación (mediante generateTokenRequestParameters)
Power BI es una herramienta que crece día a día, ofrece mucho pero aún encontramos muchas lagunas. De cara al desarrollador hay aspectos importantes que aún no están cubiertos por la versión actual de la solución. Una de ellas es el filtro a nivel de fila (seguridad a nivel de fila), el conocido como RLS (Row Level Security).
En la versión Desktop podemos emparejar un conjunto de datos con un “Role” para establecer un filtro predeterminado según el usuario que acceda a un informe. De esta manera podemos asegurarnos que por ejemplo un informe de ventas dirigido a vendedores cada uno de ellos acceda solo a sus ventas y no a la de otros vendedores.
Esta característica es básica para cualquier aplicación de Business Intelligence y estaba presente también en la reciente versión de Embedded alojada en Azure que Microsoft acaba de clausurar. En la versión Premium actual, la que está alojada en el propio servicio de Power BI y que depende de la API con la que poder manejar todos los objetos (informes, dashboards, conjuntos de datos, etc.), este concepto a fecha de hoy aún no existe.
Una de las preguntas más frecuentes de los desarrolladores es la de cómo implementar RLS en los informes que finalmente serán embebidos en sus aplicaciones. Recordemos que en estos casos los usuarios no requieren de un login en el servicio de Power BI, es la propia aplicación que es autorizada mediante un token y que por tanto Power BI desconoce que tipo de usuario accede.
La solución actual pasa por un simple filtro. Esto significa que el programador debe detectar en su aplicación qué usuario está accediendo y si el informe a mostrar requiere aplicar RLS. En caso afirmativo deberá enviar al cliente el filtro correspondiente.
En nuestras aplicaciones que tienen informes que requieren de RLS disponemos de una tabla que relaciona estos informes con los filtros correspondientes (por ejemplo tabla y campo a filtrar y la variable correspondiente -p.e. nombre de usuario-). El servidor reconoce al usuario, recoge los valores que debe aplicar y los pasa a una variable del cliente donde una función javascript lo aplica.
Primero establecemos el filtro a partir de campos ocultos que previamente el servidor ha asignado un valor (tabla_RLS, campo_RLS, valor_RLS).
var filtroRLS = {
$schema: "http://powerbi.com/product/schema#advanced",
target: {
table: tabla_RLS.GetText(),
column: campo_RLS.GetText()
},
logicalOperator: "AND",
conditions: [
{
operator: "StartsWith",
value: valor_RLS.GetText()
}
]
Y al cargar el informe debemos especificar el filtro a aplicar.
var models = window['powerbi-client'].models;
var embedConfiguration = {
type: 'report',
tokenType: models.TokenType.Embed,
accessToken: MainContent_accessToken.GetValue(),
id: MainContent_ReportID.GetValue(),
embedUrl: MainContent_ReportEmbedUrl.GetValue(),
permissions: models.Permissions.All,
filters: [filtroRLS],
settings: {
filterPaneEnabled: false,
navContentPaneEnabled: true
}
Este sistema tiene efectos colaterales. El más evidente es que si aplicamos la seguridad a nivel de fila no podemos dejar que los usuarios manejen los filtros y por tanto no podemos dejar visible el panel de filtros y tampoco podemos dejar que estos usuarios puedan tener acceso a editar los informes pues con ello podrían eliminar el filtro aplicado.