Relaciones entre políticas basadas en roles y políticas a nivel de recursos

Descripción de la relación entre las políticas basadas en roles y las políticas a nivel de recursos

En HCL Commerce, a cada acción que puede realizar un usuario se le asigna uno o más roles utilizando políticas basadas en roles como se indica a continuación:

• Cada rol predeterminado tiene un grupo de acceso correspondiente. Por ejemplo, el grupo de acceso para el rol de Vendedor es Sellers.
• Cada grupo de acceso basado en rol tiene generalmente asociadas dos políticas basadas en roles:
  • Una política que define los mandatos de controlador que el rol está autorizado a ejecutar.
  • Una política que define las acciones de vista que puede ejecutar el rol. Las acciones de vista se correlacionan con las vistas de los Archivos de configuración de Struts. Por ejemplo, OperationalReportsHomeRHSView visualiza una página web con la lista de informes de operaciones a los que tiene acceso el vendedor.

Algunos mandatos de controlador solamente tienen una política basada en roles pero ninguna política a nivel de recursos. Esto se produce si el mandato no opera en ningún recurso protegible. Por ejemplo, el mandato SetCurrencyPreferenceCmd no necesita una política a nivel de recursos ya que solo puede modificar la preferencia de moneda del usuario que ejecuta el mandato. Si pudiera cambiar la preferencia de moneda de otro usuario, el objeto de usuario tendría que estar protegido y se necesitaría una política a nivel de recursos.

Las políticas a nivel de recursos para mandatos de controlador están relacionadas directamente con determinadas políticas basadas en roles para mandatos de controlador. En la política a nivel de recursos, el mandato del controlador forma parte del grupo de acciones pero en la política basada en roles, el mandato de controlador forma parte del grupo de recursos. La figura siguiente ilustra esta relación. La política a nivel de recursos incluye los Roles A y B en el grupo de acceso, lo que hace que las políticas basadas en roles para los Roles A y B entren en acción. Mientras que la política a nivel de recursos otorga autorización a los usuarios que poseen los roles A o B para realizar determinadas acciones en un conjunto específico de recursos, las políticas basadas en roles asociadas proporcionan autorización a los usuarios que poseen los roles A y B para realizar dichas acciones en general.

Relación entre una política a nivel de recursos y las políticas basadas en roles asociadas

Este diagrama muestra una política a nivel de recursos de ejemplo que autoriza a los usuarios del grupo de acceso People a leer o estudiar determinados recursos: específicamente, libros, revistas y periódicos. Esta política se ha formulado correctamente ya que las políticas basadas en roles de los roles child y adult también les autorizan a leer o estudiar libros, revistas y periódicos8

Una política a nivel de recursos y las políticas basadas en roles que la afectan

Tenga en cuenta que en las políticas basadas en roles para mandatos de controlador:

• El grupo de acciones contiene solo una acción: Execute.
• El grupo de recursos contiene el mandato de controlador que se puede ejecutar.

Del mismo modo, en las políticas basadas en roles para vistas:

• El grupo de acciones contiene solamente las vistas que se pueden ejecutar.
• El grupo de recursos contiene un único recurso: com.ibm.commerce.command.ViewCommand.

Por otro lado, en las políticas a nivel de recursos:

• El grupo de acciones contiene el conjunto de acciones que se puede realizar en los recursos del grupo de recursos.
• El grupo de recursos contiene una lista de los recursos de negocio reales en los que pueden realizarse acciones.

Una política a nivel de recursos solamente puede autorizar a los usuarios que tienen un rol determinado a realizar acciones que ya ha autorizado la política basada en roles correspondiente. Por ejemplo, en el ejemplo anterior, el rol child tiene autorización para realizar las acciones siguientes:

• Estudiar
• Leer
• Jugar

Suponga que ahora se modifica la política a nivel de recursos para que incluya una acción nueva llamada work. Los usuarios que tienen el rol de adult podrán realizar la acción work. Sin embargo, los usuarios con el rol child no podrán. El motivo resulta aparente cuando comprueba las políticas basadas en roles de estos dos roles. La política del adult lista la acción work en el grupo de recursos. En la política de child dicha acción no aparece. Incluso si tanto el child como el adult tienen la autorización correcta de la política a nivel de recursos, la política basada en roles para el child no le autoriza a realizar la acción work.

Debido al modo en que las políticas a nivel de recursos están vinculadas con las políticas basadas en roles, el mejor modo de realizar un seguimiento de todas las políticas afectadas por un cambio determinado es retroceder a partir de la política a nivel de recursos. El primer paso es analizar el grupo de acceso de la política a nivel de recursos y determinar si contiene algún rol. Puede ver la lista completa de roles predeterminados seleccionando Gestión de acceso > Roles en la Consola de administración de organizaciones.

Si el grupo de acceso de la política a nivel de recursos incluye roles, revise las políticas basadas en roles para ver si es necesario modificarlas. Si va a añadir una acción al grupo de acciones de una política a nivel de recursos, debe asegurarse de que las políticas basadas en roles relevantes también autoricen la nueva acción. Si está suprimiendo una acción de una política a nivel de recursos y ninguna otra política a nivel de recursos hace referencia a esta acción, es mejor eliminar el recurso correspondiente de las políticas basadas en roles asociadas.

Descripción del modelo de política

Para que un usuario pueda realizar una acción, debe haber una política que lo autorice. Sin embargo, HCL Commerce permite que los usuarios realicen una acción si cualquier política proporciona la autorización necesaria. Por consiguiente, si define una política nueva más restrictiva que la política predeterminada, deberá eliminar o modificar la política predeterminada más amplia para evitar que prevalezca sobre la nueva política.

Por ejemplo, suponga que la política predeterminada A autoriza a todos los usuarios registrados a someter ofertas de subasta. Y desea cambiar esta política de modo que las ofertas de subasta estén limitadas a los usuarios que tienen el rol de comprador. Si simplemente define una nueva política que autorice a los compradores a crear ofertas de subasta, entonces la nueva política no tendrá efecto. La política predeterminada A, continuará permitiendo a los usuarios registrados a realizar ofertas de subasta. Para que la nueva política entre en vigor, deberá eliminar la política predeterminada más amplia.

La tabla siguiente resume los cambios adicionales que deberá realizar cuando cree, suprima o cambie una política a nivel de recursos.