Políticas de control de acceso de HCL Commerce
Esta sección proporciona un breve introducción a los principales componentes de la infraestructura de control de acceso de HCL Commerce. Se proporciona para que algunas de las tareas de programación relacionadas con el control de accesos se visualicen en el contexto correcto.
El modelo de control de acceso de HCL Commerce se basa en la implantación de políticas de control de acceso. Las políticas de control de acceso permiten externalizar las normas de control de acceso del código de lógica de negocio, eliminando la necesidad de grabar sentencias de control de acceso en el código. Por ejemplo, no es necesario incluir código similar al siguiente:
if (user.isAdministrator())
then {}
Las políticas de control de acceso las implementa el gestor de políticas de control de acceso. Por lo general, cuando un usuario intenta acceder a un recurso protegido, el gestor de políticas de control de acceso determina primero qué políticas de control de acceso son aplicables para ese recurso protegido y, a continuación, basándose en las políticas de control de acceso aplicables, determina si el usuario tiene permiso para acceder a los recursos solicitados.
Una política de control de acceso es una política que consta de 4 registros y que se almacena en la tabla ACPOLICY. Las políticas de control de acceso tienen el formato siguiente:
AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]
Los elementos en la política que consta de 4 registros especifican que a un usuario que pertenece a un grupo de usuarios específico se le permite realizar acciones del grupo de acciones especificado en los recursos que pertenecen al grupo de recursos especificado, a condición de que el usuario satisfaga las condiciones especificadas en la relación o grupo de relaciones, con respecto al recurso. Por ejemplo, [AllUsers, UpdateDoc, doc, creator] especifica que todos los usuarios pueden actualizar un documento, si son los creadores del mismo.
El grupo de usuarios es un tipo específico de grupo de miembros que está definido en la tabla de base de datos MBRGRP. Un grupo de usuarios debe asociarse con el tipo de grupo de miembros de -2. El valor de -2 representa un grupo de acceso y se define en la tabla MBRGRPTYPE. La asociación entre el grupo de usuarios y el tipo de grupo de miembros se almacena en la tabla MBRGRPUSG.
La pertenencia de un usuario a un grupo de usuarios particular puede indicarse explícita o implícitamente. La especificación explícita se produce si la tabla MBRGRPMBR indica que el usuario pertenece a un grupo de miembros concreto. La especificación implícita se produce si el usuario satisface una condición (por ejemplo, todos los usuarios que tienen el rol de Jefe de producto) indicada en la tabla MBRGRPCOND. También puede haber condiciones combinadas (por ejemplo, todos los usuarios que tienen el rol de Gestor de producto y que han tenido este rol durante los 6 últimos meses como mínimo) o exclusiones explícitas.
La mayor parte de las condiciones para incluir a un usuario en un grupo de usuarios se basan en el rol que tiene. Por ejemplo, puede haber una política de control de acceso que permita a todos los usuarios que tienen el rol de Jefe de producto realizar operaciones de gestión de catálogo. En este caso, cualquier usuario al que se haya asignado el rol de Gestor de producto en la tabla MBRROLE está incluido implícitamente en el grupo de usuarios.
El elemento ActionGroup viene de la tabla ACACTGRP. Un grupo de acciones hace referencia a un grupo de acciones especificado explícitamente. La lista de acciones se almacena en la tabla ACACTION y la relación de cada acción con su grupo (o grupos) de acciones se almacena en la tabla ACACTACTGP. Un ejemplo de grupo de acciones es "OrderWriteCommands". Este grupo de acciones incluye las siguientes acciones que se utilizan para actualizar pedidos:
- com.ibm.commerce.order.commands.OrderDeleteCmd
- com.ibm.commerce.order.commands.OrderCancelCmd
- com.ibm.commerce.order.commands.OrderProfileUpdateCmd
- com.ibm.commerce.order.commands.OrderUnlockCmd
- com.ibm.commerce.order.commands.OrderScheduleCmd
- com.ibm.commerce.order.commands.ScheduledOrderCancelCmd
- com.ibm.commerce.order.commands.ScheduledOrderProcessCmd
- com.ibm.commerce.order.commands.OrderItemAddCmd
- com.ibm.commerce.order.commands.OrderItemDeleteCmd
- com.ibm.commerce.order.commands.OrderItemUpdateCmd
- com.ibm.commerce.order.commands.PayResetPMCmd
Un grupo de recursos es un mecanismo para agrupar tipos de recursos específicos. La pertenencia de un recurso a un grupo de recursos puede especificarse de una de estas dos maneras:
- Utilizando la columna de condiciones en la tabla ACRESGRP
- Utilizando la tabla ACRESGPRES
En la mayoría de casos, es suficiente utilizar la tabla ACRESGPRES para asociar recursos a los grupos de recursos. Utilizando este método, los recursos se definen en la tabla ACRESCGRY utilizando su nombre de clase Java. A continuación, estos recursos se asocian a los grupos de recursos adecuados (tabla ACRESGRP) utilizando la tabla de asociaciones ACRESGPRES. En los casos en que el nombre de clases de Java no sea suficiente, por sí solo, para definir los miembros de un grupo de recursos (por ejemplo, si necesita restringir más los objetos de esta clase basándose en un atributo del recurso), el grupo de recursos puede definirse enteramente utilizando la columna de condiciones de la tabla ACRESGRP. Tenga en cuenta que para efectuar esta agrupación de recursos basándose en un atributo, el recurso debe también implementar la interfaz Groupable.
El diagrama siguiente muestra una especificación de ejemplo de agrupación de recursos. En este ejemplo, el grupo de recursos 10023 incluye todos los recursos que están asociados a él en la tabla ACRESGPRES. El grupo de recursos 10070 está definido utilizando la columna del campo de condiciones en la tabla ACRESGRP. Este grupo de recursos incluye instancias de la interfaz remota Order, que también tiene el estado = "Z" (especificando una lista de solicitudes compartida).
La columna MEMBER_ID de las tablas ACACTGRP, ACRESGRP y ACRELGRP deben tener un valor de -2001 (Organización raíz).
La política de control de acceso puede incluir, opcionalmente, un elemento Relationship o RelationshipGroup como cuarto elemento.
Si su política de control de acceso utiliza un elemento Relationship, éste proviene de la tabla ACRELATION. Si incluye un elemento RelationshipGroup, éste proviene de la tabla ACRELGRP. Tenga en cuenta que no es necesario incluir ninguno y tampoco se pueden incluir los dos. Una especificación RelationshipGroup de la tabla ACRELGRP tiene prioridad sobre la información de Relationship de la tabla ACRELATION.
La tabla ACRELATION especifica los tipos de relación existentes entre los usuarios y los recursos. Algunos ejemplos de relación son, creador, sometedor y propietario. Un ejemplo del uso del elemento de relación sería utilizarlo para asegurar que el creador de un pedido pueda siempre actualizarlo.
La tabla ACRELGRP especifica los tipos de grupos de relaciones que se pueden asociar a recursos específicos. Un grupo de relaciones consiste en una agrupación de una o más cadenas de relaciones. Una cadena de relaciones es una serie de una o más relaciones. Un ejemplo de un grupo de relaciones es especificar que un usuario debe ser el creador del recurso y, además, pertenecer a la entidad de la organización compradora a la que se hace referencia en el recurso.
La especificación del grupo de relaciones (o de la relación) es una parte opcional de la política de control de acceso. Normalmente, se utiliza si ha creado sus propios mandatos y esos mandatos no están restringidos a ciertos roles. En esos casos, quizá desee imponer una relación entre el usuario y el recurso. Normalmente, para restringir los mandatos a ciertos roles se utiliza el elemento UserGroup de la política de control de acceso, en lugar de utilizar el elemento Relationship.
Otro concepto importante relacionado con las políticas de control de acceso es el de los grupos de políticas de control de acceso. Cada modelo de negocio de WebSphere Commerce tiene su propio conjunto de políticas de control de acceso. Para agrupar los conjuntos de políticas dentro de los modelos, se utilizan grupos de políticas. Las políticas se asignan explícitamente a los grupos de políticas adecuados y, a continuación, las organizaciones se pueden suscribir a uno o varios de estos grupos de políticas. En las versiones anteriores de HCL Commerce, una política se aplicaba a todos los recursos que eran propiedad de los descendientes de la organización propietaria de dicha política.
En HCL Commerce, si una organización se suscribe a uno o más grupos de políticas, solamente las políticas contenidas en estos grupos de políticas se aplicarán a los recursos de dicha organización. Si un recurso es propiedad de una organización que no se suscribe a ningún grupo de políticas, el gestor de políticas de control de acceso busca la jerarquía de organizaciones hasta que encuentre la organización predecesora más próxima suscrita como mínimo a un grupo de políticas; una vez que se ha encontrado, aplica las políticas que pertenecen a dichos grupos de políticas.
Para los recursos que son propiedad de la Organización vendedora, se aplican las políticas del grupo de políticas de la Organización vendedora y las del grupo de políticas de la Organización raíz. Estas políticas son aplicables porque la Organización vendedora se suscribe explícitamente a esos dos grupos de políticas (las flechas de guiones muestran la suscripción). En total, se aplican tres políticas para esta organización. En este ejemplo la organización que era propietaria del recurso se suscribe explícitamente a los grupos de políticas. El diagrama también muestra un ejemplo en el que la organización no se suscribe explícitamente a ningún grupo de políticas, de modo que la infraestructura de control de acceso debe buscar más arriba en el jerarquía. Para los recursos que son propiedad de la Organización predeterminada, se debe subir por la jerarquía hasta la Organización raíz. La Organización raíz solo se suscribe a un grupo de políticas, de modo que ésas son las únicas políticas (políticas 1 y 2) que se aplican a los recursos de la Organización predeterminada.