PowerBI

Modelo de integración

Extracción de metadatos

Para la extracción de metadata de un objeto se utilizan las APIS:

• https://learn.microsoft.com/en-us/rest/api/power-bi/admin/apps-get-apps-as-admin

• https://learn.microsoft.com/en-us/rest/api/power-bi/admin/groups-get-groups-as-admin

• https://learn.microsoft.com/en-us/rest/api/power-bi/admin/datasets-get-datasets-in-group-as-admin

• https://learn.microsoft.com/en-us/rest/api/power-bi/admin/reports-get-reports-in-group-as-admin

• https://learn.microsoft.com/en-us/rest/api/power-bi/admin/dashboards-get-dashboards-in-group-as-admin

Con estas APIs se es capaz de extraer los siguientes tipos de objeto de PowerBI:

• APP

• Workspace

• Dataset (modelo de datos)

• Report

• Dashboard

El plugin extrae los siguientes atributos que deben llamarse igual en la tabla attribute_definition, campo name, para que aparezcan en la plantilla:

Además, la propia API de Azure permite devolver más atributos que, de la misma manera, para que aparezcan en Anjana Data, deben coincidir con atributos definidos en la plantilla del objeto con el mismo name. En caso de duda del valor devuelto, INPUT_TEXT siempre aceptará insertar cualquier valor.

App: https://learn.microsoft.com/en-us/rest/api/power-bi/admin/apps-get-apps-as-admin#adminapp

• El campo id se tiene que representar en Anjana como appId.

Workspace: https://learn.microsoft.com/en-us/rest/api/power-bi/admin/groups-get-groups-as-admin#admingroup

• El campo id se tiene que representar en Anjana como workspaceId.

• El campo state se tiene que representar en Anjana como workspaceState.

• El campo dataflows y workbook no se recupera al ser un tipo aparte de datos que se extraerá en futuras versiones.

• El campo users no se recupera al estar deprecada por PowerBi

• La información relativa a dashboards, dataset y reports se extrae como una lista de nombres, con un campo especifico para cada uno.

• El campo logAnalyticsWorkspace no se recupera por limitaciones de la API.

• El campo type se tiene que representar en Anjana como workspaceType.

Dataset (modelo de datos) : https://learn.microsoft.com/en-us/rest/api/power-bi/admin/datasets-get-datasets-in-group-as-admin

• El campo id se tiene que representar en Anjana como semanticModelId.

• El campos tags no se recupera al solo estar disponible en API de Fabric a la creación de este documento.

• El campo users no se recupera al estar deprecado por PowerBi.

• El campo ContentProviderType no se recupera al estar deprecado por PowerBi.

Report: https://learn.microsoft.com/en-us/rest/api/power-bi/admin/reports-get-reports-in-group-as-admin

• El campo id se tiene que representar en Anjana como reportId.

• El campos tags no se recupera al solo estar disponible en API de Fabric a la creación de este documento.

• El campo subscriptions y users no se recuperan al estar deprecados por PowerBi.

Dashboard: https://learn.microsoft.com/en-us/rest/api/power-bi/admin/dashboards-get-dashboards-in-group-as-admin

• El campo id se tiene que representar en Anjana como dashboardId.

• El campo displayName se incluira en Anjana como el campo genérico name.

• El campos tags no se recupera al solo estar disponible en API de Fabric a la creación de este documento.

• El campo subscriptions y users no se recuperan al estar deprecados por PowerBi.

Tablas con caracteres en el nombre

Esta tecnología permite los caracteres como “/” en el nombre, si se están usando, se debe configurar el path-separator con otro carácter que no sea “/”. Consultar Extracción de ficheros para más detalles.

Gestión de accesos

El Tot Plugin de Power BI incorpora la gestión de accesos sobre los activos de Power BI catalogados en Anjana Data Platform. La funcionalidad permite asignar y revocar permisos efectivos en Power BI a partir del ciclo de vida de un DSA, utilizando grupos de Azure Entra ID como única unidad de autorización.

El modelo garantiza un comportamiento determinista, idempotente y trazable, y se apoya en los siguientes principios de diseño:

• Autorización basada en grupos, los permisos se conceden siempre a grupos de Azure Entra ID, nunca a usuarios individuales. Cualquier cambio en la composición del grupo se refleja en Power BI de forma indirecta.

• Separación de responsabilidades, la gestión de identidades y grupos corresponde al Tot Plugin de Azure Entra ID; el Tot Plugin de Power BI actúa exclusivamente sobre la capa de autorización de los recursos de Power BI.

• Privilegio mínimo, el nivel de permiso concedido es fijo por tipo de objeto y no configurable por DSA, lo que garantiza consistencia entre entornos.

• Idempotencia, el plugin comprueba el estado actual antes de actuar. Repetir una asignación o una revocación no produce efectos secundarios ni errores funcionales.

• Procesamiento best-effort, en operaciones sobre varios objetos, el fallo en uno de ellos no interrumpe el procesamiento del resto; los objetos con error se devuelven identificados en la respuesta.

Reparto de responsabilidades entre plugins

Quedan fuera del alcance del plugin de Power BI la creación y eliminación de grupos en Entra ID, la gestión de usuarios dentro de los grupos, las llamadas directas a Microsoft Graph API y la persistencia de información.

Alcance sobre los activos de Power BI

Power BI gestiona el acceso mediante un modelo de seguridad por capas en el que la visibilidad del Workspace, el acceso a los datos del Dataset y la publicación de Apps son mecanismos distintos. El plugin se apoya únicamente en los mecanismos de Workspace y Dataset, que son los únicos automatizables mediante la API REST de Power BI.

Los permisos concedidos sobre un Workspace se propagan automáticamente a todo el contenido que aloja. Los datasets y modelos semánticos también heredan del Workspace, pero admiten además asignación aislada.

Configuración en Anjana Data Platform

Este apartado recoge las actuaciones que debe realizar el cliente en Anjana Data Platform para que la gestión de accesos sobre Power BI opere correctamente.

Requisitos previos

• Tot Plugin de Azure Entra ID, desplegado y configurado, ya que es el responsable de crear y resolver los grupos que el plugin de Power BI utiliza como unidad de autorización.

• Activos catalogados, los objetos de Power BI deben haberse incorporado previamente al Catalog mediante la extracción de metadatos.

Operativa de concesión y retirada de accesos

1. Crear un DSA e incluir en él entidades de tipo WORKSPACE o DATASET/SEMANTIC_MODEL.

2. Aprobar el DSA. El plugin asigna al grupo asociado el permiso Viewer sobre los Workspaces y Read sobre los datasets o modelos semánticos incluidos.

3. Expirar el DSA cuando el acceso deba retirarse. El plugin revoca los permisos previamente concedidos sobre los objetos del DSA.

Uso de grupos corporativos preexistentes (physicalName)

Cuando el DSA informa el atributo physicalName, el grupo asociado se considera preexistente y gestionado externamente. En ese escenario, el Tot Plugin de Azure Entra ID no crea ni elimina el grupo, únicamente resuelve su identificador, mientras que el plugin de Power BI evalúa el estado actual de los permisos antes de aplicar cualquier cambio.

Es responsabilidad del cliente garantizar que el grupo reutilizado cumple las siguientes condiciones:

• Sin permisos previos incompatibles, sobre los recursos de Power BI incluidos en el DSA.

• Sin roles superiores, a los previstos por el modelo de privilegio mínimo.

• Sin permisos conflictivos, sobre los mismos recursos.

Si se detectan permisos incompatibles, el plugin rechaza la operación sobre el objeto afectado y la registra como error.

Recomendaciones de modelado

• Granularidad, dado que el nivel mínimo gestionable es el Workspace, la segregación de accesos debe planificarse organizando el contenido en Workspaces separados.

• Dependencias entre Workspaces, conviene verificar que los reports y apps incluidos en el alcance no consuman datasets alojados en otros Workspaces, ya que esas dependencias no se cubren automáticamente.

Este apartado está dirigido principalmente a administradores funcionales de la plataforma y a los responsables de la administración del tenant de Power BI.

Limitaciones y consideraciones conocidas

• Granularidad limitada al Workspace y al Dataset, Power BI no permite gestionar permisos de forma directa sobre reports, dashboards y apps. El acceso a estos objetos se obtiene por herencia del Workspace y no se garantiza control granular por objeto individual.

• Dependencias entre Workspaces, la versión actual no detecta que un report, dashboard o app consuma datasets alojados en otros Workspaces, ni emite advertencias funcionales. Un usuario puede tener acceso al Workspace y no visualizar correctamente determinados contenidos por falta de permisos sobre datasets externos.

• Sincronización entre Entra ID y Power BI, la propagación de un grupo recién creado no es instantánea. El plugin reintenta de forma automática ante los errores transitorios asociados a este retardo, conforme a la política configurada.

• Throttling de la API de Power BI, el límite estándar es de aproximadamente 120 solicitudes por minuto y Service Principal. Ante una respuesta de limitación, el plugin reintenta según los parámetros countRetry y waitRetry.

• Expiración sobre report y dashboard, queda fuera de alcance. El nivel mínimo de expiración aplicable es el Workspace o el dataset/modelo semántico.

• Trazabilidad con correlationId, la propagación de un identificador de correlación extremo a extremo queda fuera del alcance de la versión actual.

Clasificación de errores

El plugin normaliza el resultado de cada elemento procesado y clasifica los errores en las siguientes categorías, devolviendo los objetos con error identificados en la respuesta.

Credenciales requeridas

Extracción de metadatos

Se necesitan los siguientes permisos:

• Ser administrador de las workspace que se quieren extraer metadata.

Estos permisos se deben dar sobre el service principal que se vaya a usar para el cometido del plugin. Estos permisos no pueden ser consentimiento de Administración si no que tienen que ser permisos delegados:

1. Configuración del App Registration

   1. Ir al Azure Portal.

   2. Navegar a Azure Active Directory > App registrations > + New registration.

   3. Proporcionar un nombre para la aplicación y seleccionar el tipo de cuenta (lo más común es Accounts in this organizational directory only).

Gestión de accesos

La gestión de accesos se ejecuta con la misma identidad técnica que la extracción de metadatos: un Service Principal de Azure Entra ID que se autentica frente a la API REST de Power BI mediante OAuth2 client credentials. Las credenciales (clientId, clientSecret y tenantId) se configuran en application-default.yaml.

Permisos en Azure Entra ID

• User.Read.All, configurado sobre la App Registration utilizada por el plugin.

Requisitos en Power BI

Los permisos de Entra ID no son suficientes por sí solos: la capacidad efectiva de gestión depende del modelo de autorización interno de Power BI. Se requiere adicionalmente:

1. Generar un grupo de seguridad en Azure específico para consumir las APIs de PowerBI

   1. Meter dentro del grupo la APP generada

   2. Meter al grupo dentro de la siguiente opción existente en PowerBI (ver captura)

1. Habilitación del Service Principal, en el portal de administración de Power BI debe estar activada la opción «Allow service principals to use Power BI APIs», con el grupo de seguridad que contiene la aplicación incluido en dicha opción.

2. Rol Admin sobre el Workspace, el Service Principal debe estar asignado como Admin en cada Workspace objetivo sobre el que el plugin vaya a asignar, revocar o consultar permisos.

Resumen de configuración por responsable