Generación de un token de inserción
SE APLICA A: 
La aplicación es la propietaria de los datos 
El usuario es el propietario de los datos
Generar token es una API REST que permite generar un token para incrustar un informe de Power BI o un modelo semántico en una aplicación web o un portal. Puede generar un token para un único elemento o para varios informes o modelos semánticos. El token se usa para autorizar la solicitud en el servicio Power BI.
La API de generación de tokens usa una única identidad (una entidad de servicio o usuario maestro) para generar un token para un usuario individual, en función de las credenciales de ese usuario en la aplicación (identidad efectiva).
Después de la autenticación correcta, se concede el acceso a los datos pertinentes.
Nota:
Generar token es la API más reciente, versión 2, que funciona tanto para informes como para modelos semánticos, y para uno o varios elementos. Es preferible sobre las API heredadas de la versión 1. En el caso de los paneles y iconos, use Dashboards GenerateTokenInGroup y Tiles GenerateTokenInGroup, de la versión 1.
Protección de los datos
Si se ocupa del tratamiento de datos de varios clientes, hay principalmente dos enfoques para proteger dichos datos: el aislamiento basado en el área de trabajo y el aislamiento basado en la Seguridad de nivel de fila. Puede ver una comparación detallada entre ellos en la sección Seguridad de nivel de fila de la página Perfiles de entidad de servicio para aplicaciones de varios clientes en Power BI Embedded.
Se recomienda usar el aislamiento basado en el área de trabajo con los perfiles, pero, si desea usar el enfoque de RLS, revise la sección de RLS al final de este artículo.
Permisos de token y seguridad
En las API de generación de tokens, la sección GenerateTokenRequest describe los permisos de token.
Nivel de acceso
Use el parámetro allowEdit para conceder al usuario permisos de visualización o edición.
Agregue el identificador del área de trabajo al token de inserción para permitir al usuario crear nuevos informes (ya sea SaveAs o CreateNew) en esa área de trabajo.
Seguridad de nivel de fila
Con la Seguridad de nivel de fila (RLS), la identidad que utilice puede ser diferente de la identidad de la entidad de servicio o del usuario maestro que esté usando para generar el token. Al usar identidades diferentes, puede mostrar información insertada según el usuario al que se dirija. Por ejemplo, en la aplicación puede pedir a los usuarios que inicien sesión y, a continuación, mostrar un informe que solo contenga información de ventas si el usuario que inició sesión es un empleado de ventas.
Si utiliza RLS, en algunos casos, puede omitir la identidad del usuario (parámetro EffectiveIdentity). Cuando no se usa el parámetro EffectiveIdentity, el token tiene acceso a toda la base de datos. Este método puede utilizarse para conceder acceso a usuarios como administradores y directores, que tienen permiso para ver todo el modelo semántico. Sin embargo, no puede usar este método en todos los escenarios. En la tabla siguiente se enumeran los distintos tipos de RLS y se muestra el método de autenticación que se puede usar sin especificar la identidad de un usuario.
En la tabla también se muestran las consideraciones y limitaciones aplicables a cada tipo de RLS.
| Tipo de RLS | ¿Se puede generar un token de inserción sin especificar el identificador de usuario efectivo? | Consideraciones y limitaciones |
|---|---|---|
| Seguridad de nivel de fila en la nube (RLS en la nube) | ✔ Usuario maestro ✖ Entidad de servicio |
|
| RDL (informes paginados) | ✖ Usuario maestro ✔ Entidad de servicio |
No puede usar un usuario maestro para generar un token de inserción para RDL. |
| Conexión dinámica local de Analysis Services (AS) | ✔ Usuario maestro ✖ Entidad de servicio |
El usuario que genera el token de inserción también necesita uno de los siguientes permisos: |
| Conexión dinámica de Azure de Analysis Services (AS) | ✔ Usuario maestro ✖ Entidad de servicio |
No se puede reemplazar la identidad del usuario que genera el token de inserción. Los datos personalizados se pueden utilizar para implementar RLS dinámico o filtrado seguro. Nota: La entidad de servicio debe proporcionar su identificador de objeto como identidad efectiva (el nombre de usuario de RLS). |
| Inicio de sesión único (SSO) | ✔ Usuario maestro ✖ Entidad de servicio |
Se puede proporcionar una identidad explícita (SSO) mediante la propiedad de blob de identidad en un objeto de identidad efectiva. |
| SSO y RLS en la nube | ✔ Usuario maestro ✖ Entidad de servicio |
Debe proporcionar lo siguiente: |
Nota
Las entidades de servicio siempre deben proporcionar la siguiente información:
- Una identidad para cualquier elemento con un modelo semántico RLS.
- Para un modelo semántico SSO, una identidad RLS efectiva con la identidad contextual (SSO) definida.
DirectQuery para modelos semánticos de Power BI
Para integrar un informe de Power BI que tiene un modelo semántico con una conexión de Consulta directa a otro modelo semántico de Power BI, haga lo siguiente:
- En el portal de Power BI, establezca el punto de conexión XMLA en Solo lectura o Lectura y escritura, como se describe en Habilitación de la lectura y escritura para una capacidad Premium. Solo tendrá que hacerlo una vez para cada capacidad.
- Genere un token de inserción de varios recursos.
- Especifique todos los identificadores de conjunto de datos en la solicitud.
- Establezca el
XmlaPermissionsa Solo lectura para cada modelo semántico de la solicitud. - Para cada origen de datos habilitado para el inicio de sesión único (SSO), proporcione el blob de identidad para el origen de datos en
DatasourceIdentity.
Renovación de tokens antes de que expiren
Los tokens vienen con un límite de tiempo. Esto significa que, después de insertar un elemento de Power BI, tiene una cantidad limitada de tiempo para interactuar con él. Para ofrecer a los usuarios una experiencia continua, renueve (o actualice) el token antes de que expire.
Paneles e iconos
El Generar token funciona para informes y modelos semánticos. Para generar un token de inserción para un panel o icono, use las API Dashboards GenerateTokenInGroup o Tiles GenerateTokenInGroup de la versión 1. Estas API generan tokens solo para un elemento cada vez. No se puede generar un token para varios elementos.
Para estas API:
Use el parámetro accessLevel para determinar el nivel de acceso del usuario.
Ver: conceda permisos de visualización al usuario.
Editar: conceda permisos de visualización y edición al usuario (solo se aplica al generar un token de inserción para un informe).
Crear: conceda al usuario permisos para crear un informe (solo se aplica al generar un token de inserción para crear un informe). Para la creación de informes, también debe proporcionar el parámetro datasetId.
Use el valor booleano allowSaveAs para permitir que los usuarios guarden el informe como un nuevo informe. Esta configuración se establece en false de forma predeterminada y solo se aplica al generar un token de inserción para un informe.
Consideraciones y limitaciones
Por motivos de seguridad, la duración del token de inserción se establece en la duración restante del token de Microsoft Entra que se usa para llamar a la API de
GenerateToken. Por lo tanto, si usa el mismo token de Microsoft Entra para generar varios tokens de inserción, la duración de los tokens de inserción generados será más corta con cada llamada.Si el modelo semántico y el elemento que se va a integrar se encuentran en dos áreas de trabajo diferentes, el servicio principal o el usuario principal deben ser al menos miembros de ambas áreas de trabajo.
No se puede crear un token de inserción para Mi área de trabajo.