Configurar la seguridad usando permisos de tabla

Nota

A partir del 12 de octubre de 2022, los portales de Power Apps son Power Pages. Más información: Microsoft Power Pages ya está disponible para el público en general (blog)
Pronto migraremos y fusionaremos la documentación de los portales de Power Apps con la documentación de Power Pages.

Para aplicar la seguridad en portales a registros individuales, use permisos de tabla. Agregue permisos de tabla a roles web para poder definir roles en su organización que se correspondan de forma lógica con los privilegios y conceptos de propiedad y acceso a registros. Recuerde que un contacto dado puede pertenecer a un número indefinido de roles y que un rol determinado puede incluir un número indefinido de permisos de tabla. Más información: Crear roles web para portales.

Aunque los permisos para cambiar y acceder a las URL en un mapa del sitio del portal se conceden a través de la Autorización de contenido, los administradores del sitio también querrán proteger las aplicaciones web personalizadas creadas con formularios básicos y listas. Más información: Definir formularios básicos y Definir listas.

Para garantizar estas características, los permisos de tabla permiten que se concedan derechos granulares y que se habilite la seguridad a nivel de registro mediante definiciones de relación.

Agregar permisos de tabla a un rol web

1. Abra la aplicación Administración del portal.

2. Vaya a Portales > Roles web y abra el rol web al que desea agregar permisos.

3. Bajo Relacionados, seleccione Permisos de tabla.

4. Seleccione Agregar permiso de tabla existente para agregar un permiso de tabla existente a un rol web.

5. Busque un permiso de tabla o seleccione Permiso de mesa nueva para crear un nuevo registro de permiso de tabla.

   

Al crear un nuevo registro de permiso de tabla, el primer paso es determinar la tabla que se protegerá. El siguiente paso es definir el tipo de acceso, como se explica en la siguiente sección, y—para cualquier tipo de acceso que no sea Global—las relaciones que definen ese tipo de acceso. Por último, se determinan los derechos que se conceden al rol con dicho permiso. Los derechos son acumulativos, por lo que si un usuario tiene un rol que concede derechos de Lectura y otro que concede Lectura y Actualización, el usuario tendrá derechos de Lectura y Actualización para cualquier registro que se superponga entre los dos roles.

Nota

La selección de tablas como la página web, los archivos web y otras tablas de configuración no es válida y podría tener otras consecuencias no deseadas. El portal valorará la seguridad de las tablas de configuración en función de los controles de acceso al contenido, no de los permisos de la tabla.

Tipo de acceso global

Si se concede un registro de permiso de tabla con derechos de Lectura a un rol que tiene el tipo de acceso global, cualquier contacto de dicho rol tendrá acceso a todos los registros de la tabla definida. Por ejemplo, puede ver todos los clientes potenciales, todas las cuentas, etc. Este permiso será respetado automáticamente por cualquier lista, esencialmente mostrando todos los registros de acuerdo con las vistas de Microsoft Dataverse que se han definido para esa lista. Además, si un usuario intenta acceder a un registro a través de un formulario básico al que no tiene acceso, recibirá un error de permiso. Por ejemplo, consulte este escenario de ejemplo para mostrar todos los listados de automóviles a todos los usuarios autenticados en un concesionario de automóviles.

Tipo de acceso al contacto

Con el tipo de acceso de contacto, un usuario que ha iniciado sesión en el rol para el que se define el registro del permiso tendrá los derechos que otorga dicho permiso solo para los registros que están relacionados con el registro de contacto de ese usuario a través de una relación definida.

En una lista, el tipo de acceso significa que un filtro se agregará a las vistas de Microsoft Dataverse que hayan emergido de esa lista, que recupera solo los registros vinculados al usuario actual directamente. (En función del escenario, esta relación se puede considerar como derechos de propiedad o de administración). Por ejemplo, consulte este escenario de ejemplo para mostrar, actualizar y eliminar listados de automóviles en propiedad en un concesionario de automóviles.

Los formularios básicos solo concederán el permiso apropiado para Leer, Crear, Escribir, etc., si esta relación existe ya cuando se carga el registro. Más información: Definir formularios básicos.

Tipo de acceso a la cuenta

Con el tipo de acceso de cuenta, un usuario que haya iniciado sesión en el rol para el que se define el registro del permiso tendrá los derechos que otorga dicho permiso solo para los registros que estén relacionados con el registro de cuenta primaria de ese usuario, a través de una relación definida.

Este tipo de acceso significa que la lista solo mostrará los registros de la tabla seleccionada que están asociados a la cuenta primaria del usuario. Por ejemplo, si un permiso de tabla permite el acceso de lectura a una tabla de clientes potenciales con el tipo de acceso Cuenta, el usuario que tiene este permiso puede ver todos los clientes potenciales de solo la cuenta primaria del usuario. Por ejemplo, vea este escenario de ejemplo para permitir que el personal vea todos los concesionarios de automóviles propiedad de su empresa.

Tipo de acceso autónomo

El tipo de acceso autónomo permite definir los derechos que tiene un usuario sobre su propio registro de Contacto (Identidad). Los usuarios pueden utilizar formularios básicos o de varios pasos para introducir cambios en su propio registro de Contacto vinculado a su perfil. La página de perfil predeterminada tiene un formulario integrado especial que permite a cualquier usuario cambiar su información de contacto básica y optar por inscribirse o borrarse de las listas de marketing. Si este formulario se incluye en el portal (que es la opción predeterminada), los usuarios no necesitarán este permiso para usarlo. Sin embargo, necesitarán este permiso para usar cualquier formulario básico o formulario de varios pasos personalizado que tenga como objetivo su registro de contacto de usuario. Por ejemplo, vea este escenario de ejemplo que permite al personal de un concesionario de automóviles actualizar sus detalles de contacto en su página de perfil.

Tipo de acceso primario

En el caso más complejo, se conceden permisos para una tabla que se encuentra fuera de una tabla para la cual ya se ha definido ya un registro de Permiso de tabla. Este permiso es en realidad un registro secundario del permiso de la tabla primaria.

El registro de permiso primario define un permiso y un tipo de acceso para una tabla (probablemente tipo de acceso global o de contacto, aunque también puede ser primario). Dicha tabla podría estar relacionada con un contacto (si hay un tipo de acceso de contacto) o definida globalmente. Con ese permiso, se crea un permiso secundario que define una relación de otra tabla con la tabla definida en la relación primaria.

Los usuarios en un rol web que tengan acceso a los registros definidos por el permiso de la tabla primaria también tendrán los derechos definidos por el permiso secundario para los registros relacionados con el registro primario.

Atributos y relaciones

En la siguiente tabla se explican los atributos de los permisos de tabla.

Nombre	Descripción
Nombre	El nombre descriptivo del registro. Este campo es obligatorio.
Nombre de tabla	El nombre lógico de la tabla que se va a proteger o que definirá la relación de contacto o la relación primaria para asegurar una tabla relacionada con un permiso secundario. Este campo es obligatorio.
Tipo de acceso (obligatorio)	Global: Conceda privilegios al registro de tabla sin requisitos para un propietario (contacto). Contacto: Conceda privilegios al registro de tabla que tiene una relación directa con un propietario (contacto). Cuenta: Conceda privilegios al registro de tabla que tiene una relación con una cuenta, que sirve como propietario, suponiendo que la cuenta es el cliente principal del contacto. Principal: Conceda privilegios al registro de tabla a través de la cadena de relaciones de permisos primarios.
Relación para el tipo de acceso	Depende del tipo de acceso seleccionado. Relación de contacto: Requerido solo si Tipo de acceso = Contacto. El nombre de esquema de la relación entre el contacto y la tabla especificada por el campo Nombre de tabla. Relación de cuenta: Requerido solo si Tipo de acceso = Cuenta. El nombre de esquema de la relación entre la cuenta y la tabla especificada por el campo Nombre de tabla. Relación principal: Obligatorio solo si se asigna un permiso de tabla primaria. El nombre de esquema de la relación entre la tabla especificada por el campo Nombre de tabla y la tabla especificada por el campo Nombre de tabla en su registro de permiso de tabla principal. Permiso de tabla principal: Requerido solo si Tipo de acceso = Principal. Nota: las relaciones disponibles estarán vacías si el Contacto o la Cuenta no tienen relaciones existentes con la tabla seleccionada. Para crear la tabla Relaciones, consulte Descripción general de la tabla Relaciones.
Leído	Privilegio que controla si el usuario puede leer un registro.
Escribir	Privilegio que controla si el usuario puede actualizar un registro.
Crear	Privilegio que controla si el usuario puede crear un nuevo registro. El derecho a crear un registro para un tipo de tabla no se aplica a un registro individual, sino a una clase de tablas.
Delete	Privilegio que controla si el usuario puede eliminar un registro.
Anexar	Privilegio que controla si el usuario puede adjuntar otro registro al registro especificado. Los derechos de acceso Anexar y Anexar a trabajan en combinación. Cada vez que un usuario adjunte un registro a otro, debe tener ambos derechos. Por ejemplo, si adjunta una nota a un caso, debe tener el derecho de acceso Anexar en la nota y el derecho de acceso Anexar a en el caso para que la operación funcione.
Anexar a	Privilegio que controla si el usuario puede anexar el registro en cuestión a otro registro. Los derechos de acceso Anexar y Anexar a trabajan en combinación, según se describe arriba.

Permisos globales para tareas relacionadas con clientes potenciales

En un escenario, es posible que deseemos utilizar una lista y formularios básicos para mostrar todos los clientes potenciales en el portal a cualquier persona con un rol web personalizado de administrador de clientes potenciales. En el formulario de edición de clientes potenciales, que se inicia cada vez que se selecciona una fila de cliente potencial en la lista, una subcuadrícula mostrará los registros de tareas relacionados. Estos registros deben estar accesibles para cualquier persona con el rol de administrador de clientes potenciales. Como primer paso, le daremos permisos globales a los clientes potenciales a cualquier persona en nuestro rol de administrador de clientes potenciales.

Este rol tiene un permiso de tabla relacionado para la tabla de cliente potencial, con un tipo de acceso global.

Los usuarios con este rol pueden acceder a todos los clientes potenciales a través de listas o formularios del portal.

Ahora agregaremos un permiso secundario al permiso de cliente potencial global. Con el registro de Permiso primario abierto, vaya a la subcuadrícula Permisos de tabla secundaria y seleccione Nuevo permiso de tabla para agregar un nuevo registro.

Seleccione la tabla como Tareas y el tipo de acceso como Primario. A continuación, puede seleccionar la relación principal (Lead_Tasks). Este permiso implica que un contacto en un rol web con el Permiso primario tendrá permiso global para todas las tareas relacionadas con los clientes potenciales.

Para que su lista respete estos permisos:

• Permisos de tabla debe estar habilitado en la lista.

  

• Debe haber acciones que realmente permitan a los usuarios realizar las acciones para las que se han otorgado los permisos.

  

• Los permisos también deben estar habilitados en el registro de formulario básico.

  

• El formulario debe mostrar una página que tenga una subcuadrícula para la tabla que desea habilitar con permisos secundarios. En este caso, la tabla será Tareas.

  

Si desea habilitar los permisos Leer o Crear en las tareas, también deberá configurar esos formularios básicos y editar los formularios para eliminar el campo de búsqueda Referente a.

Esta acción concede permisos para todas las tareas relacionadas con clientes potenciales. Si las tareas se muestran en una lista, se agrega un filtro a la lista para que solo se aparezcan en la lista las tareas relacionadas con un cliente potencial. En nuestro ejemplo, aparecen con una subcuadrícula en un formulario básico.

Permisos de tipo de acceso de contacto para tareas

Otro ejemplo sería el que quisiera permitir el acceso a tareas en las que un contacto está relacionado con el cliente potencial primario de dicha tarea. Este escenario es casi idéntico al ejemplo de la sección anterior, excepto que en este caso el permiso primario tiene un tipo de acceso de Contacto, en lugar de Global. Se debe especificar una relación en la relación primaria entre la tabla del cliente principal y la tabla del contacto.

Una vez que se apliquen estos permisos, los usuarios en el rol de administrador de clientes potenciales pueden acceder a los clientes potenciales relacionados directamente con ellos por el permiso de tipo de acceso de contacto, además de acceder a las tareas relacionadas con esos mismos clientes potenciales según lo especificado en el registro de permiso secundario.

Consultar también

Crear roles web para portales
Controlar el acceso a páginas web para los portales

Nota

¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)

La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).