Implementar el control de acceso

Policy Manager es el componente de control de acceso que determina si el usuario actual puede ejecutar la acción especificada en el recurso especificado. Las políticas de control de acceso están especificadas en formato XML. Durante la creación de la instancia, las políticas predeterminadas y los grupos de políticas predeterminados se cargan en las tablas de base de datos correspondientes. Cuando HCL Commerce Application Server se inicia, la información de control de acceso se almacena en la memoria caché para que el Gestor de políticas pueda comprobar rápidamente la autorización de un usuario cuando se le solicita. Si se modifica la información de control de acceso en la base de datos mediante la Consola de administración o cargando datos de política XML, es necesario actualizar la memoria caché de control de acceso. Puede actualizar la memoria caché actualizando el registro adecuado en la Consola de administración. Si se cambian los datos de políticas, actualice el registro de Políticas de control de acceso. Si se cambian los datos de grupos de políticas, actualice el registro Grupos de políticas de control de acceso. El reinicio de HCL Commerce también actualiza la memoria caché.

Cuando un usuario intenta actúa en un recurso protegido, se produce una comprobación de control de acceso para asegurarse de que el usuario tiene autorización. El Gestor de políticas gestiona las políticas de control de acceso que se aplican a la organización propietaria del recurso. A continuación, comprueba estas políticas y evalúa si el usuario está autorizado a realizar la acción en el recurso de destino. Si encuentra como mínimo una de estas políticas, el Gestor de políticas otorga el acceso; de lo contrario, lo deniega.

Niveles de control de acceso

Existen dos niveles generales de control de acceso en HCL Commerce: nivel de mandatos (también conocido como basado en roles) y nivel de recursos (también conocido como nivel de instancias).

Diagrama de niveles de control de acceso.

Control de acceso a nivel de mandatos o basado en roles

El control de acceso a nivel de mandatos o basado en roles es control de acceso menos filtrado. Determina quién puede hacer qué en la tienda actual. Con el control de acceso basado en roles, puede especificar que todos los usuarios de un rol determinado puedan ejecutar determinados mandatos dentro de la tienda actual. Si no se ha seleccionado ninguna tienda, la comprobación de roles no abarcará ninguna tienda u organización particular. Se puede tomar como ejemplo la política de control de acceso: los vendedores pueden ejecutar mandatos de vendedores. En esta política, uno de los mandatos de vendedores es el mandato CatalogUpdate. En la figura anterior, José y Pedro son los vendedores, por lo que los dos pueden ejecutar el mandato UpdateCatalog. Sin embargo, sólo pueden ejecutar este mandato si la tienda actual pertenece a una organización en la que tienen el rol de vendedor.

El control de acceso basado en roles se utiliza para mandatos de controlador y vistas. Este tipo de control de acceso sólo toma en consideración la tienda actual y no ningún otro recurso de bajo nivel. Sólo determina si al usuario se le permite ejecutar una vista o mandato de controlador específico. Este nivel de control de acceso es obligatorio y se impone durante la ejecución.

Control de acceso a nivel de mandatos para mandatos de controlador: Cuando ejecuta un mandato de controlador, debe existir una política de control de acceso que permita a los usuarios realizar la acción Execute en el recurso de mandato. El recurso es el nombre de la interfaz del mandato de controlador. El grupo de acceso normalmente está dentro del ámbito de un solo rol. Por ejemplo, puede especificar que los usuarios que tengan el rol de Representante de cuentas puedan ejecutar cualquier mandato del grupo de recursos AccountRepresentativesCmdResourceGroup.
Control de acceso a nivel de mandatos para vistas: Cuando se llama directamente a una vista desde el URL, o si es el resultado de una redirección desde un mandato, debe tener una política de control de acceso. Dicha política debe tener especificado el viewname como una acción en la tabla ACACTION. Esta acción debe tener un grupo de acciones asociado mediante la tabla ACACTACTGP. A continuación, debe hacerse referencia a este grupo de acciones en la política a nivel de mandatos adecuada en la tabla ACPOLICY.

Control de acceso a nivel de instancias o a nivel de recursos

Las políticas de control de acceso a nivel de instancias o a nivel de recursos proporcionan un control de acceso general, ya que determinan quién puede ejecutar qué mandato en qué recursos de la tienda actual. Los vendedores pueden modificar objetos que son propiedad de la organización para la que desempeñan su rol. Por ejemplo, si el usuario A tiene el rol de vendedor para la organización vendedora 1 y el usuario B tiene el rol de vendedor para la organización vendedora 2. El usuario A crea una subasta de muebles en la tienda de muebles. El usuario B crea una categoría de camisas en la tienda de camisas. El usuario A puede modificar la categoría de muebles, pero no la categoría de camisas. El usuario B puede modificar la categoría de camisas pero no la categoría de muebles.

Resumiendo, el primer sistema realiza una comprobación de acceso a nivel de mandatos. Si se le permite al usuario ejecutar un mandato, se creará una política de control de acceso a nivel de recursos posterior para determinar si el usuario puede acceder al recurso en cuestión.

El control de acceso a nivel de recursos se aplica a mandatos y a beans de datos.

Control de acceso a nivel de recursos para mandatos

Una vez completada la comprobación de control de acceso a nivel de mandatos, si se otorga acceso, se lleva a cabo la comprobación a nivel de recursos en uno de los dos casos siguientes:

El mandato implementa getResources(). Este método especifica las instancias de los recursos que es necesario comprobar en la acción actual, donde el mandato es ahora la acción. El tiempo de ejecución de HCL Commerce exige que el usuario actual tenga acceso a todos los recursos especificados por getResources(). De forma predeterminada, getResources() devuelve un valor nulo, es decir, que no comprueba el acceso a nivel de recursos.
El mandato llama a checkIsAllowed(Object Resource, String Action) en los casos en los que la persona que escribe el mandato no sabe qué recursos es necesario comprobar en el momento en que la ejecución llama a getResources(), el mandato puede llamar a este método checkIsAllowed() si es necesario para determinar si está autorizada la pareja actual de acción y recurso. La acción es generalmente el nombre de la interfaz del mandato actual. Cuando se llama a este método y se deniega el acceso, se genera una excepción: ECApplicationException( ECMessage._ERR_USER_AUTHORITY, ..)

Control de acceso a nivel de recursos par beans de datos: Las vistas están protegidas por políticas a nivel de mandatos, que suelen estar basadas en roles. Por ejemplo, la política a nivel de mandatos puede especificar que un administrador de vendedores tenga acceso a una vista específica. Normalmente es necesario asegurarse de forma adicional de que todos los beans de datos de la JSP estén relacionados con la organización para la que el usuario desempeña el rol de Administrador de vendedores. Esto se lleva a cabo haciendo que todos los beans de datos que necesitan (directa o indirectamente) protección implementen la interfaz Delegator. Estos delegados beans de datos en un bean de datos primario (independiente), que a su vez implementa la interfaz protegible. Un bean de datos primario delega en sí mismo e implementa ambas interfaces. Siempre que se invoca un bean de datos con el método activate() del gestor de beans de datos, el tiempo de ejecución de HCL Commerce garantiza que hay una política que concede al usuario actual la autorización para realizar la acción Display en el recurso de bean de datos primario.