Perfiles de entidad de servicio para aplicaciones de varios inquilinos en Power BI Embedded

  • Artículo

En este artículo se explica cómo un ISV o cualquier otro propietario de la aplicación Power BI Embedded que tenga muchos clientes puede usar perfiles de entidad de servicio para asignar y administrar los datos de cada cliente como parte de su solución de inserción de Power BI para los clientes. Los perfiles de entidad de servicio permiten al ISV crear aplicaciones escalables que permitan un mejor aislamiento de los datos del cliente y establezcan límites de seguridad más estrictos entre los clientes. En este artículo se describen las ventajas y las limitaciones de esta solución.

Nota:

La palabra inquilino en Power BI a veces puede hacer referencia a un inquilino de Microsoft Entra. Sin embargo, en este artículo se usa el término multiinquilino para describir una solución en la que una única instancia de una aplicación de software atiende a varios clientes u organizaciones (inquilinos) que requieren separación física y lógica de los datos. Por ejemplo, el generador de aplicaciones de Power BI puede asignar un área de trabajo independiente para cada uno de sus clientes (o inquilinos), tal como se muestra a continuación. Estos clientes no son necesariamente inquilinos de Microsoft Entra, por lo que no confunda el término aplicación multiinquilino que usamos aquí, con la aplicación multiinquilino de Microsoft Entra.

Un perfil de entidad de servicio es un perfil creado por una entidad de servicio. La aplicación del ISV llama a las API de Power BI mediante un perfil de entidad de servicio, tal como se explica en este artículo.

La entidad de servicio de la aplicación del ISV crea un perfil de Power BI diferente para cada cliente o inquilino. Cuando un cliente visita la aplicación del ISV, la aplicación usa el perfil correspondiente para generar un token de inserción que se usará para representar un informe en el explorador.

El uso de perfiles de entidad de servicio permite que la aplicación del ISV hospede varios clientes en un único inquilino de Power BI. Cada perfil representa un cliente en Power BI. En otras palabras, cada perfil crea y administra el contenido de Power BI para los datos de un cliente específico.

Diagrama de perfiles SP y multiinquilino.

Nota

Este artículo está dirigido a organizaciones que quieran configurar una aplicación de varios inquilinos mediante perfiles de entidad de servicio. Si su organización ya tiene una aplicación que admite varios inquilinos y quiere realizar una migración al modelo de perfil de entidad de servicio, consulte Migración al modelo de perfiles de entidad de servicio.

La configuración del contenido de Power BI implica los pasos siguientes:

Todos los pasos anteriores se pueden automatizar completamente mediante las API REST de Power BI.

Prerrequisitos

Para poder crear perfiles de entidad de servicio, debe:

  • Configure la entidad de servicio siguiendo los tres primeros pasos de Inserción de contenido de Power BI con la entidad de servicio.
  • Desde una cuenta de administrador de inquilinos de Power BI, habilite la creación de perfiles en el inquilino con el mismo grupo de seguridad que usó al crear la entidad de servicio.

Captura de pantalla del interruptor del portal de administración.

Creación de un perfil

Los perfiles se pueden crear, actualizar y eliminar mediante la API REST Profiles.

Por ejemplo, para crear un perfil:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Una entidad de servicio también puede llamar a la API REST GET Profiles para obtener una lista de sus perfiles. Por ejemplo:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Permisos de perfil

Cualquier API que conceda permiso de usuario a los elementos de Power BI también puede conceder un permiso de perfil a los elementos de Power BI. Por ejemplo, la API Add Group User se puede usar para conceder un permiso de perfil a un área de trabajo.

Los siguientes puntos son importantes para comprender cuándo se usan perfiles:

  • Un perfil pertenece a la entidad de servicio que la creó y solo la puede usar esa entidad de servicio.
  • Un propietario del perfil no se puede cambiar después de la creación.
  • Un perfil no es una identidad independiente. Necesita la entidad de servicio token de Microsoft Entra para llamar a las API REST de Power BI.

Las aplicaciones del ISV llaman a las API REST de Power BI proporcionando el token de Microsoft Entra de la entidad de servicio en el encabezado Authorization y el identificador de perfil en el encabezado X-PowerBI-Profile-Id. Por ejemplo:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Crear un área de trabajo

Las áreas de trabajo de Power BI se usan para hospedar elementos de Power BI, como informes y modelos semánticos.

Cada perfil debe:

  • Crear al menos un área de trabajo de Power BI

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Conceda permisos de acceso al área de trabajo. El perfil de la entidad de servicio debe tener acceso de Administrador al área de trabajo.

  • Asignar el nuevo área de trabajo a una capacidad

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Lea más sobre las áreas de trabajo de Power BI.

Importación de informes y modelos semánticos

Use Power BI Desktop para preparar informes conectados a los datos del cliente o a los datos de ejemplo. A continuación, puede usar la API Import para importar el contenido en el área de trabajo creada.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Use parámetros de modelos semánticos para crear un modelo semántico que pueda conectarse a distintos orígenes de datos de los clientes. A continuación, use la API Actualizar parámetros para definir a qué datos de los clientes se conecta el modelo semántico.

Establecimiento de la conexión del modelo semántico

Los ISV suelen almacenar los datos de sus clientes de una de estas dos maneras:

En cualquier caso, debe terminar con modelos semánticos de inquilino único (un modelo semántico por cliente) en Power BI.

Una base de datos independiente para cada cliente

Si la aplicación del ISV tiene una base de datos independiente para cada cliente, cree modelos semánticos de un solo inquilino en Power BI. Proporcione a cada modelo semántico detalles de conexión que apunten a su base de datos coincidente. Use uno de los métodos siguientes para evitar la creación de varios informes idénticos con detalles de conexión diferentes:

  • Parámetros del modelo semántico: cree un modelo semántico con parámetros en los detalles de conexión (como el nombre de SQL Server o el nombre de la base de datos SQL). A continuación, importe un informe en el área de trabajo de un cliente y cambie los parámetros para que coincidan con los detalles de la base de datos del cliente.

  • Actualización de la API Update Datasource: cree un archivo .pbix que apunte a un origen de datos con contenido de ejemplo. A continuación, importe el archivo .pbix en el área de trabajo de un cliente y cambie los detalles de conexión mediante la API Update Datasource.

Una sola base de datos de varios inquilinos

Si la aplicación del ISV usa una base de datos para todos sus clientes, separe los clientes en modelos semánticos diferentes en Power BI de la siguiente manera:

Cree un informe mediante parámetros que solo recuperen los datos del cliente pertinentes. A continuación, importe un informe en el área de trabajo de un cliente y cambie los parámetros para recuperar solo los datos de datos del cliente correspondientes.

Inserción de un informe

Una vez completada la instalación, puede insertar informes de clientes y otros elementos en la aplicación mediante un token de inserción.

Cuando un cliente visite la aplicación, use el perfil correspondiente para llamar a la API GenerateToken. Use el token de inserción generado para insertar un informe u otros elementos en el explorador del cliente.

Para generar un token de inserción:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Aspectos de diseño

Antes de configurar una solución de varios inquilinos basada en perfiles, debe tener en cuenta los siguientes problemas:

Escalabilidad

Al separar los datos en modelos semánticos independientes para cada cliente, se minimiza la necesidad de modelos semánticos de gran tamaño. Cuando se sobrecarga la capacidad, puede expulsar los modelos semánticos sin usar para liberar memoria para los modelos semánticos activos. Esta optimización es imposible para un único modelo semántico de gran tamaño. Mediante el uso de varios modelos semánticos, también puede separar los inquilinos en varias capacidades de Power BI si es necesario.

Sin perfiles, una entidad de servicio está limitada a 1000 áreas de trabajo. Para superar este límite, una entidad de servicio puede crear varios perfiles, donde cada perfil puede tener acceso o crear hasta 1000 áreas de trabajo. Con varios perfiles, la aplicación del ISV puede aislar el contenido de cada cliente mediante contenedores lógicos distintos.

Una vez que un perfil de entidad de servicio tiene acceso a un área de trabajo, se puede quitar el acceso de su entidad de servicio principal al área de trabajo para evitar problemas de escalabilidad.

Incluso con estas ventajas, debe tener en cuenta la posible escala de la aplicación. Por ejemplo, el número de elementos del área de trabajo a los que puede tener acceso un perfil es limitado. Hoy en día, un perfil tiene los mismos límites que un usuario normal. Si la aplicación del ISV permite a los usuarios finales guardar una copia personalizada de sus informes incrustados, el perfil de un cliente tendrá acceso a todos los informes creados de todos sus usuarios. Este modelo puede superar finalmente el límite.

Automatización y complejidad operativa

Con la separación basada en el área de trabajo de Power BI, podría necesitar administrar cientos o miles de elementos de Power BI. Es importante definir los procesos que se producen con frecuencia en la administración del ciclo de vida de la aplicación y asegurarse de que tiene el conjunto correcto de herramientas para realizar estas operaciones a escala. Entre estas operaciones se incluyen:

  • Adición de un nuevo inquilino
  • Actualización de un informe para algunos inquilinos o todos ellos
  • Actualización del esquema del modelo semántico para algunos inquilinos o todos ellos
  • Personalizaciones no planeadas para inquilinos específicos
  • Frecuencia de actualizaciones del modelo semántico

Por ejemplo, la creación de un perfil y un área de trabajo para un nuevo inquilino es una tarea común, que se puede automatizar completamente con la API REST de Power BI.

Necesidades de Multi-Geo

La compatibilidad de Multi-Geo con Power BI Embedded significa que los ISV y las organizaciones que compilan aplicaciones con Power BI Embedded para insertar análisis en sus aplicaciones ahora pueden implementar sus datos en diferentes regiones de todo el mundo. Para admitir otros inquilinos en otras regiones, asigne el área de trabajo del cliente a una capacidad en la región deseada. Esta tarea es una operación sencilla que no implica costos adicionales. Sin embargo, si tiene clientes que necesitan datos de varias regiones, el perfil de inquilino debe duplicar todos los elementos en varias áreas de trabajo asignadas a distintas capacidades regionales. Esta duplicación puede aumentar tanto el costo como la complejidad de la administración.

Por motivos de cumplimiento, es posible que desee crear varios inquilinos de Power BI en distintas regiones. Obtenga más información sobre las zonas geográficas múltiples.

Rentabilidad

Los desarrolladores de aplicaciones que usan Power BI Embedded deben adquirir la capacidad de Power BI Embedded. El modelo de separación basado en perfiles funciona bien con capacidades porque:

  • El objeto más pequeño que puede asignar de forma independiente a una capacidad es un área de trabajo (por ejemplo, no se puede asignar un informe). Al separar los clientes por perfiles, obtiene áreas de trabajo diferentes: una por cliente. De este modo, obtendrá una flexibilidad completa para administrar cada cliente según sus necesidades de rendimiento y optimizar el uso de la capacidad mediante el escalado o reducción vertical. Por ejemplo, puede administrar clientes grandes y esenciales con alto volumen y volatilidad en una capacidad separada para garantizar un nivel de servicio coherente, agrupando los inquilinos más pequeños en otra capacidad para optimizar los costos.

  • Las áreas de trabajo separadas implican también la separación de los modelos semánticos entre inquilinos para que los modelos de datos puedan estar en fragmentos más pequeños, en lugar de en un único modelo semántico de gran tamaño. Estos modelos más pequeños permiten administrar el uso de memoria de forma más eficaz. Los modelos semánticos pequeños y sin usar se pueden expulsar después de un período de inactividad, con el fin de mantener un buen rendimiento.

Al comprar una capacidad, debe tener en cuenta el límite del número de actualizaciones paralelas, ya que los procesos de actualización pueden requerir capacidad adicional al tener varios modelos semánticos.

Seguridad de nivel de fila

En este artículo se explica cómo usar perfiles para crear un modelo semántico independiente para cada cliente. Como alternativa, las aplicaciones del ISV pueden almacenar todos los datos de sus clientes en un modelo semántico de gran tamaño y usar la seguridad de nivel de fila (RLS) para proteger los datos de cada cliente. Este enfoque puede ser conveniente para los ISV que tienen relativamente pocos clientes y modelos semánticos pequeños a medianos porque:

  • Solo hay un informe y un modelo semántico para mantener
  • El proceso de incorporación para los nuevos clientes se puede simplificar

Sin embargo, antes de usar RLS, asegúrese de comprender sus limitaciones. Todos los datos de todos los clientes se encuentran en un modelos semánticos de Power BI de gran tamaño. Este modelo semántico se ejecuta en una sola capacidad con su propio escalado y otras limitaciones.

Incluso si usa perfiles de entidad de servicio para separar los datos de los clientes, puede seguir usando RLS dentro del modelo semántico de un solo cliente para conceder a distintos grupos acceso a diferentes partes de los datos. Por ejemplo, podría usar RLS para impedir que los miembros de un departamento accedan a los datos de otro departamento de la misma organización.

Consideraciones y limitaciones

  • Los perfiles de entidad de seguridad solo se admiten a través de la API de REST de BI de Power y el SDK .NET de Power BI. Los perfiles de entidad de seguridad no son compatibles con Power BI a través del punto de conexión XMLA o el Modelo de objetos tabulares (TOM).
  • Los perfiles de entidad de servicio no se admiten con Azure Analysis Services (AAS) en modo de conexión dinámica.

Limitaciones de capacidad de Power BI

Administración de entidades de servicio

Cambio a una entidad de servicio

En Power BI, un perfil pertenece a la entidad de servicio que la creó. Esto significa que un perfil no se puede compartir con otras entidades de seguridad. Con esta limitación, si desea cambiar la entidad de servicio por cualquier motivo, deberá volver a crear todos los perfiles y proporcionar a los nuevos perfiles acceso a las áreas de trabajo pertinentes. A menudo, la aplicación del ISV debe guardar una asignación entre un identificador de perfil y un identificador de cliente para elegir el perfil correcto cuando sea necesario. Si cambia la entidad de servicio y vuelve a crear los perfiles, los identificadores también cambiarán y es posible que tenga que actualizar la asignación en la base de datos de la aplicación del ISV.

Eliminación de una entidad de servicio

Advertencia

Tenga mucho cuidado al eliminar una entidad de servicio. No desea perder accidentalmente datos de todos sus perfiles asociados.

Si elimina la entidad de servicio en Active Directory, se eliminarán todos sus perfiles en Power BI. Sin embargo, Power BI no eliminará el contenido inmediatamente, por lo que el administrador de inquilinos todavía puede acceder a las áreas de trabajo. Tenga cuidado al eliminar una entidad de servicio que se usa en un sistema de producción, especialmente cuando haya creado perfiles con esta entidad de servicio en Power BI. Si elimina una entidad de servicio que ha creado perfiles, tenga en cuenta que tendrá que volver a crear todos los perfiles, proporcionar a los nuevos perfiles acceso a las áreas de trabajo pertinentes y actualizar los identificadores de perfil en la base de datos de la aplicación del ISV.

Separación de datos

Cuando los datos están separados por perfiles de entidad de servicio, una asignación sencilla entre un perfil y un cliente impide que un cliente vea el contenido de otro cliente. El uso de una sola entidad de servicio requiere que la entidad de servicio tenga acceso a todas las distintas áreas de trabajo de todos los perfiles.

Para agregar una separación adicional, puede asignar una entidad de servicio independiente a cada inquilino, en lugar de tener una sola entidad de servicio con acceso a varias áreas de trabajo mediante perfiles diferentes. La asignación de entidades de servicio independientes tiene varias ventajas, entre las que se incluyen:

  • El error humano o una pérdida de credenciales no hará que se expongan los datos de varios inquilinos.
  • La rotación de certificados se puede realizar por separado para cada inquilino.

Sin embargo, el uso de varias entidades de servicio conlleva un alto costo de administración. Seleccione esta ruta de acceso solo si necesita la separación adicional. Tenga en cuenta que la configuración de los datos que se muestran a un usuario final se define durante la generación del token de inserción, un proceso de solo back-end que los usuarios finales no pueden ver ni cambiar. Al solicitar un token de inserción mediante un perfil específico del inquilino, se generará un token de inserción para ese perfil específico, que proporcionará a sus clientes una separación del consumo.

Un informe, varios modelos semánticos

Por lo general, tiene un informe y un modelo semántico por inquilino. Si tiene cientos de informes, tendrá cientos de modelos semánticos. A veces, es posible que tenga un formato de informe, con distintos modelos semánticos (por ejemplo, parámetros o detalles de conexión diferentes). Cada vez que tenga una nueva versión del informe, deberá actualizar todos los informes de todos los inquilinos. Aunque puede automatizar esto, es más fácil administrar si solo tiene una copia del informe. Cree un área de trabajo que contenga el informe que quiere insertar. Durante el tiempo de ejecución de la sesión, puede enlazar el informe al modelo semántico específico del inquilino. Lea el artículo sobre enlaces dinámicos para obtener más detalles.

Personalización y creación de contenido

Al crear contenido, tenga en cuenta cuidadosamente a quién permite editarlo. Si permite que varios usuarios de cada inquilino lo editen, es fácil superar las limitaciones del modelo semántico. Si decide proporcionar esta capacidad de edición a los usuarios, es recomendable supervisar estrechamente la generación de contenido y escalar verticalmente según sea necesario. Por las mismas razones, no se recomienda usar esta capacidad para la personalización de contenido, donde cada usuario puede realizar pequeños cambios en un informe y guardarlo por su cuenta. Si la aplicación del ISV permite la personalización de contenido, considere la posibilidad de introducir directivas de retención del área de trabajo para contenido específico del usuario. Las directivas de retención facilitan la eliminación de contenido cuando los usuarios pasan a una nueva posición, dejan la empresa o dejan de usar la plataforma.

Identidad administrada por el sistema

En lugar de una entidad de servicio, puede usar unaidentidad administrada asignada por el usuario o asignada por el sistema para crear perfiles. Las identidades administradas reducen la necesidad de secretos y certificados.

Tenga cuidado al usar una identidad administrada por el sistema porque:

  • Si una identidad administrada asignada por el sistema está desactivada accidentalmente, perderá el acceso a los perfiles. Esta situación es similar a un caso en el que se elimina una entidad de servicio.
  • Una identidad administrada asignada por el sistema está conectada a un recurso de Azure (aplicación web). Si elimina el recurso, la identidad administrada se eliminará también.
  • El uso de varios recursos (diferentes aplicaciones web en regiones diferentes) dará lugar a varias identidades que deban administrarse por separado (cada identidad tendrá sus propios perfiles).

Debido a las consideraciones anteriores, se recomienda usar una identidad administrada asignada por el usuario.

Ejemplo

Para obtener un ejemplo de cómo usar perfiles de entidad de servicio para administrar un entorno multiinquilino con la inserción de Power BI y App-Owns-Data, descargue el repositorio La aplicación posee los datos del multiinquilino de Power BI Dev Camp (sitio de terceros).

Contenido relacionado