Autenticación y autorización con Power BI Embedded

El servicio Power BI Embedded usa claves y tokens de aplicación para la autenticación y la autorización en lugar de la autenticación explícita de usuario final. En este modelo, la aplicación, la aplicación administra la autenticación y la autorización de sus usuarios finales. Si es necesario, la aplicación crea y envía los tokens de aplicación que indican a nuestro servicio que presente el informe solicitado. En este diseño no es necesario que la aplicación use Azure Active Directory para la autenticación y la autorización de usuarios, aunque puede hacerlo.

Dos modos de autenticación

Clave: puede usar claves para todas las llamadas de API de REST de Power BI Embedded. Las claves pueden encontrarse en Azure portal haciendo clic en Toda la configuración y, luego, en Claves de acceso. Debe tratar siempre la clave como si fuese una contraseña. Estas claves tienen permisos para llamar a cualquier API de REST en una colección de área de trabajo determinada.

Para utilizar una clave en una llamada de REST, agregue el siguiente encabezado de autorización:

Copy

 

Authorization: AppKey {your key}

Token de aplicación : los tokens de aplicación se utilizan para todas las solicitudes de inserción. Están diseñados para ejecutarse en el lado del cliente, por lo que están restringidas a un único informe y se recomienda establecer un tiempo de expiración.

Los tokens de aplicación son un JWT (JSON Web Token) que está firmado por una de sus claves.

El token de la aplicación puede contener las siguientes notificaciones:

Notificación	Description
ver	La versión del token de aplicación. La versión actual es 0.2.0.
aud	El destinatario previsto del token. Para usar Power BI Embedded: "https://analysis.windows.net/powerbi/api".
iss	Una cadena que indica la aplicación que emitió el token.
type	El tipo de token de aplicación que se está creando. El único tipo admitido actualmente es insertar.
wcn	El nombre de la colección de área de trabajo para el que se emite el token.
wid	El id. del área de trabajo para el que se emite el token.
rid	El id. del informe para el que se emite el token.
username (opcional)	Se utiliza con RLS y es una cadena que ayuda a identificar el usuario cuando se aplican las reglas RLS.
roles (opcional)	Una cadena que contiene los roles que seleccione al aplicar las reglas de seguridad de nivel de fila. Si se pasa más de un rol, se deben pasar como una matriz de cadenas.
exp (opcional)	Indica la hora a la que caducará el token. Se deben pasar como marcas de tiempo de Unix.
nbf (opcional)	Indica la hora a la que comienza a ser válido el token. Se deben pasar como marcas de tiempo de Unix.

Un ejemplo de token de aplicación tendrá este aspecto:

Cuando se descodifica, tendrá un aspecto similar al siguiente:

Funcionamiento del flujo

1. Copie las claves de API a la aplicación. Puede obtener las claves en el Portal de Azure.
   
2. El token impone una notificación y tiene un tiempo de expiración.
   
3. El token se firma con las claves de acceso de la API.
   
4. El usuario solicita ver un informe.
   
5. El token se valida con claves de acceso de una API.
   
6. Power BI Embedded envía un informe al usuario.
   

Después de que Power BI Embedded envíe un informe al usuario, este puede ver el informe en su aplicación personalizada. Por ejemplo, si ha importado el ejemplo .pbix de análisis de datos de venta, la aplicación web de ejemplo tendría el siguiente aspecto:

Seguridad de nivel de fila con Power BI Embedded

Seguridad de nivel de fila (RLS) puede utilizarse para restringir el acceso de usuario a datos determinados dentro de un informe o un conjunto de datos, lo que permite a los distintos usuarios utilizar el mismo informe mientras todos ven datos diferentes. Power BI Embedded ahora admite conjuntos de datos configurados con RLS.

Para sacar el máximo partido de RLS, es importante comprender tres conceptos principales: usuarios, roles y reglas. Profundicemos en cada uno de ellos:

Usuarios : estos son los usuarios finales reales que ven los informes. En Power BI Embedded, los usuarios se identifican por la propiedad de nombre de usuario en un token de la aplicación.

Roles : los usuarios pertenecen a roles. Un rol es un contenedor de reglas y se puede adoptar un nombre como "Administrador de ventas" o "Representante de ventas". En Power BI Embedded, los usuarios se identifican por la propiedad de roles en un token de la aplicación.

Reglas : los roles tienen reglas y dichas reglas son los filtros reales que se van a aplicar a los datos. Esto podría ser tan simple como "Country = USA" o algo mucho más dinámico.

Ejemplo

Durante el resto de este artículo, presentaremos un ejemplo de la creación de un RLS y después su consumo dentro de una aplicación incrustada. Nuestro ejemplo utiliza el archivo PBIX del ejemplo de análisis de venta minorista .

Nuestro ejemplo de análisis de venta minorista muestra las ventas de todas las tiendas de una determinada cadena minorista. Sin RLS, no importa qué administrador de distrito inicia sesión y ve el informe, todos verán los mismos datos. Los directivos han determinado que cada administrador de distrito solo debe ver las ventas de los almacenes que administra y, para ello, podemos usar RLS.

RLS se ha creado en Power BI Desktop. Cuando se abren el conjunto de datos y el informe, podemos cambiar a la vista de diagrama para ver el esquema:

Estas son algunas cosas a tener en cuenta con este esquema:

• Todas las medidas, como Total Sales, se almacenan en la tabla de hechos Sales.
• Hay cuatro tablas de dimensiones adicionales relacionadas: Item, Time, Store y District.
• Las flechas en las líneas de relación indican de qué forma los filtros pueden fluir de una tabla a otra. Por ejemplo, si se coloca un filtro en Time[Date], en el esquema actual solo se deberían filtrar valores de la tabla Sales. Ninguna otra tabla se vería afectada por este filtro, ya que todas las flechas en las líneas de relación apuntan a la tabla de ventas y ninguna a otro lado.
• La tabla District indica quién es el administrador de cada distrito:
  

En función de este esquema, si se aplica un filtro a la columna District Manager de la tabla District y si el filtro coincide con el usuario que está viendo el informe, dicho filtro también filtrará las tablas Store y Sales solo para mostrar los datos de ese administrador de distrito determinado.

Este es el procedimiento:

1. En la pestaña Modelado, haga clic en Administrar roles.
   
2. Cree un nuevo rol denominado Manager.
   
3. En la tabla District escriba la siguiente expresión de DAX: [District Manager] = USERNAME()
   
4. Para asegurarse de que funcionan las reglas, en la pestaña Modelado haga clic en la pestaña Ver como roles y, después, escriba lo siguiente:
   
   Los informes mostrarán ahora los datos como si hubiera iniciado sesión como Andrew Ma.

Al aplicar el filtro, tal como hicimos aquí, se filtrarán todos los registros de las tablas District, Store y Sales. Sin embargo, debido a la dirección del filtro en las relaciones entre las tablas Sales y Time, Sales e Item, y Item y Time no se filtrarán.

Puede que sea correcto para este requisito, sin embargo, si no queremos que los administradores vean aquellos elementos para los cuales no tengan ninguna venta, podríamos activar el filtrado cruzado bidireccional para la relación y dirigir el filtro de seguridad en ambas direcciones. Esto puede hacerse mediante la edición de la relación entre Sales e Item, de la forma siguiente:

Ahora, los filtros también pueden fluir de la tabla Sales a la tabla Items :

Nota Si utiliza el modo DirectQuery para los datos, debe habilitar el filtrado cruzado bidireccional mediante la selección de estas dos opciones:

1. Archivo -> ** Opciones y configuración** -> Características de vista previa -> Enable cross filtering in both directions for DirectQuery (Habilitar filtrado cruzado en ambas direcciones para DirectQuery).
2. Archivo -> Opciones y configuración -> DirectQuery -> Allow unrestricted measure in DirectQuery mode (Permitir medida sin restricciones en el modo DirectQuery).

Para más información acerca de filtrado cruzado bidireccional, descargue el documento Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop ([Filtrado cruzado bidireccional en SQL Server Analysis Services 2016 y Power BI Desktop]).

Esto concluye todo el trabajo que debe hacerse en Power BI Desktop, pero hay una más parte del trabajo que debe hacerse para que funcionen las reglas de RLS que definimos en Power BI Embedded. Los usuarios se autentican y autorizan por su aplicación y se utilizan tokens de la aplicación para conceder a ese usuario acceso a un informe de Power BI Embedded específico. Power BI Embedded no tiene información específica en quién es el usuario. Para que RLS funcione, debe pasar contexto adicional como parte de su token de aplicación:

• username (opcional): se utiliza con RLS y es una cadena que puede usarse para ayudar a identificar el usuario cuando se aplican las reglas RLS. Consulte el uso de la seguridad de nivel de fila con Power BI Embedded
• roles : una cadena que contiene las funciones que seleccione al aplicar las reglas de seguridad de nivel de fila. Si se pasa más de un rol, se deben pasar como una matriz de cadenas.

Si la propiedad username está presente, también debe pasar al menos un valor en los roles.

El token de la aplicación completo tendrá un aspecto similar al siguiente:

Ahora, con todas las piezas juntas, cuando un usuario inicie sesión en nuestra aplicación para ver este informe, solo podrá ver los datos que tenga permiso para ver, tal como se ha definido en nuestra seguridad de nivel de fila.