Política de control de acceso

Elementos de una política de control de acceso

Una política de control de acceso se compone de cuatro elementos:

Grupo de acceso

El grupo de usuarios al que se aplica la política.

Grupo de acciones

Un grupo de acciones que el usuario realiza en los recursos.

Grupo de recursos

Los recursos controlados por la política. Un grupo de recursos puede incluir objetos de negocio como, por ejemplo contract o order, o bien un conjunto de mandatos relacionados. POr ejemplo, todos los mandatos que los usuarios de un determinado rol puede realizar.

Relación

Opcional: Cada clase de recurso puede tener asociado un conjunto de relaciones. Cada recurso puede tener un conjunto de usuarios que satisfacen cada relación. Por ejemplo, una política puede especificar que sólo el creador de un pedido pueda modificarlo. En este caso, la relación sería la de creator, y es entre el usuario y el recurso de pedido.

Estas cuatro partes juntas definen una política en HCL Commerce especificando los usuarios, las acciones que éstos pueden realizar, el objeto de negocio o el conjunto de mandatos en los que se efectúan las acciones y, opcionalmente, la relación que los usuarios tienen con el grupo de recursos.

Las políticas de control de acceso otorgan a los usuarios acceso al sitio. A menos que estén autorizados a ejercer sus responsabilidades mediante una o varias políticas de control de acceso, los usuarios no tienen acceso a funciones del sitio.

AccessControlPolicy [AccessGroup,ActionGroup,ResourceGroup,Relationship]

Los elementos de la política de control de acceso especifican que un usuario que pertenece a un grupo determinado de usuarios puede llevar a cabo las acciones del grupo de acciones especificado, en los recursos pertenecientes al grupo de recursos especificado, siempre que el usuario satisfaga una relación determinada con respecto al recurso. La relación solamente se especifica cuando se necesita. Por ejemplo, [AllUsers,UpdateDoc,doc,creator] especifica que todos los usuarios pueden actualizar un documento, si son los creadores del mismo.

Los apartados siguientes describen los conceptos y la terminología asociada al control de acceso.

Grupos de miembros

El subsistema de miembros de HCL Commerce le permite crear grupos de miembros, que son grupos de usuarios agrupados por categorías por diferentes motivos comerciales. Las agrupaciones se pueden utilizar para muchos fines, por ejemplo para fines de control de acceso, fines de aprobación, así como para fines de marketing, como la calificación de promociones y la visualización de productos. Un grupo de miembros de tipo Grupo de acceso (-2) se utiliza para fines de control de acceso, mientras que un grupo de miembros de tipo Grupo de usuarios (-1) es para fines de uso general. Un grupo de miembros se asocia a los tipos de grupos de miembros de la tabla MBRGRPUSG.

Grupos de acceso

Un grupo de miembros de tipo Grupo de acceso (-2) se utiliza para agrupar usuarios para fines de control de acceso. Un grupo de acceso es un elemento de una política de control de acceso. Los criterios para la pertenencia a un grupo de acceso normalmente están basados en roles, en la organización a la que pertenece el usuario y en el estado de registro del usuario. Por ejemplo, un grupo de miembros llamado Buyer Administrators es un grupo cuyos usuarios desempeñan el rol de Administrador de compradores.

HCL Commerce incluye varios roles predeterminados y a cada rol le corresponde un grupo de acceso predeterminado que hace referencia implícitamente a dicho rol. Los roles se pueden utilizar como atributos para añadir usuarios a un grupo de acceso basándose en el tipo de actividades que realizan en el sitio. Por ejemplo, de forma predeterminada hay un rol llamado Administrador de vendedores y un grupo de acceso correspondiente llamado Seller Administrators. Un administrador de sitio utiliza la Administration Console para crear, mantener y eliminar grupos de acceso para un sitio. Un administrador de sitio, un administrador de compradores, un administrador de vendedores o un gestor de canales utiliza la Organization Administration Console para asignar roles a los usuarios o para asignar explícitamente usuarios a grupos de acceso.

Grupo de acceso implícito

Un grupo de acceso implícito se define mediante un conjunto de criterios. Cualquiera que satisfaga los criterios es un miembro del grupo. Los criterios suelen estar basados en los roles, la organización padre o el estado de registro de un usuario. Las condiciones implícitas que definen la pertenencia a un grupo de miembros están en la columna CONDITIONS de la tabla MBRGRPCOND. La utilización de grupos de acceso implícitos que especifican los atributos de usuarios facilita el poder autorizar el acceso a usuarios similares sin tener que asignar ni desasignar explícitamente usuarios individuales. También elimina la necesidad de actualizar los miembros de un grupo cuando se modifican los atributos de un usuario. Asimismo, dado que varios grupos de acceso pueden hacer referencia al mismo atributo de usuario, al asignar un atributo a un usuario se puede incluir implícitamente dicho usuario en varios grupos de acceso. Un criterio sencillo para un grupo de acceso es incluir a todos aquellos a los que se ha asignado un rol específico, independientemente de la organización para la que el usuario desempeña el rol. Un criterio más complejo sería especificar que sólo los usuarios que desempeñan uno de los roles de un conjunto de roles posibles para una organización determinada pueden pertenecer al grupo de acceso.

Grupo de acceso explícito

También se puede añadir o eliminar de forma explícita un usuario de un grupo de miembros. Estas dos especificaciones explícitas se pueden llevar a cabo mediante la tabla MBRGRPMBR. Un grupo de acceso explícito contiene usuarios asignados explícitamente que pueden compartir o no atributos comunes. También permite excluir a los individuos que, aunque satisfacen las condiciones de inclusión en un grupo definido implícitamente, desea excluir.

Grupos de usuarios

Un grupo de miembros de tipo Grupo de usuarios (-1) es un conjunto de usuarios, definido por el comerciante, que comparten un interés común. Los grupos de usuarios son similares a los clubes que ofrecen los grandes almacenes para sus clientes habituales o preferidos. El hecho de formar parte de un grupo de usuarios puede dar derecho a los clientes a promociones u otras bonificaciones para comprar productos. Por ejemplo, si la investigación de mercado muestra que los clientes de más edad compran repetidamente libros de viajes y equipaje, puede asignar estos clientes a un grupo de miembros llamado Seniors' Travel Club. Del mismo modo, puede crear un grupo de usuarios para recompensar a los clientes habituales por sus compras.

Acciones

Generalmente, una acción es una operación que se realiza en un recurso. En las políticas basadas en roles para mandatos de controlador, la acción es Execute y el recurso es el mandato que se ejecuta. En las políticas basadas en roles para Vistas, la acción es el nombre de la vista y el recurso es com.ibm.commerce.commands.ViewCommand. En el control de acceso a nivel de recursos, normalmente las acciones se correlacionan con mandatos de HCL Commerce y el recurso es generalmente la interfaz remota de un EJB (Enterprise Java Bean) protegido. Por ejemplo, el mandato de controlador com.ibm.commerce.order.commands.OrderCancelCmd funciona en el recurso com.ibm.commerce.order.objects.Order Finalmente, en las políticas de bean de datos, se utiliza la acción Display para permitir la activación de recursos de bean de datos.

Un Administrador de sitio puede utilizar la Administration Console para asociar acciones existentes con grupos de acciones, pero no para crear acciones nuevas. Se pueden crear acciones nuevas definiéndolas en un archivo XML y, a continuación, cargándolas en la base de datos. Las acciones se almacenan en la tabla ACACTION.

Grupos de acciones

Los grupos de acciones son grupos de acciones relacionadas. Un ejemplo de un grupo de acciones es el grupo AccountManage que incluye los mandatos siguientes:

• com.ibm.commerce.account.commands.AccountDeleteCmd
• com.ibm.commerce.account.commands.AccountSaveCmd

Sólo el Administrador de sitio puede crear, actualizar y eliminar grupos de acciones. Esto puede llevarse a cabo desde la Administration Console y mediante XML. Los grupos de acciones se almacenan en la tabla ACACTGRP. Las acciones se asocian con grupos de acciones de la tabla ACACTACTGP.

Categoría de recursos

Una categoría de recursos hace referencia a una clase de recursos que deben protegerse mediante el control de acceso. Los recursos deben implementar la información de la interfaz Protectable. Las categorías de recursos son clases Java como pedido y RFQ. Los recursos son las instancias de estas clases. Por ejemplo, Order1 creado por el Administrador de pedidos A es un recurso; Order2 creado por el Administrador de pedidos B es otro recurso. Estos dos recursos pertenecen a la categoría de recursos: duplicado.

Las categorías de recursos se definen en la tabla ACRESCGRY y, por comodidad, a veces se hace referencia a las mismas como recursos. Un Administrador de sitio puede asociar las categorías de recursos existentes con grupos de recursos, utilizando la Administration Console. Mediante XML se pueden crear nuevas categorías de recursos.

Recursos

Los recursos son los objetos del sistema que deben protegerse. Por ejemplo, las RFQ, los usuarios y los pedidos son algunos de los recursos de HCL Commerce que es necesario proteger. Cada recurso tiene un propietario. La propiedad del recurso se utiliza para determinar las políticas de control de acceso que se le aplican. Las políticas de control de acceso tienen un propietario, que es una entidad de organización. Una política sólo se aplica a los recursos que son propiedad de la misma entidad de organización que se ha suscrito a un grupo de políticas que contiene la política. Si la organización que posee dicho recurso no se ha suscrito a ningún grupo de políticas, entonces se aplican las políticas de los grupos de políticas a los que se ha suscrito la organización predecesora más próxima.

Recursos de mandatos de controlador

En el control de acceso basado en roles para mandatos de controlador, la política se estructura de tal modo que la acción Execute se realiza en el recurso de mandato de controlador. Estas políticas están diseñadas para limitar la ejecución de los mandatos de controlador a los usuarios que tienen un rol especificado. El grupo de acceso de estas políticas generalmente es para los que tienen un único rol, por ejemplo, los jefes de producto (los que tienen el rol de Jefe de producto). A continuación, el grupo de recursos deberá ser el conjunto de mandatos de controlador que un jefe de producto puede ejecutar.

Mientras se implementa un control de acceso basado en roles en un mandato del controlador, se debe determinar el propietario del mandato. Esto se efectúa llamando al método getOwner() del mandato, si se ha implementado. Dado que generalmente este método no se implementa, la ejecución de HCL Commerce lo evaluará realizando una de las acciones siguientes:

• Utilizando la organización propietaria de la tienda que actualmente está en el contexto del mandato.
• Si el contexto del mandato no contiene ninguna tienda, se utilizará la organización raíz como propietario.

Recursos de beans de datos

No todos los beans de datos requieren protección. En la aplicación HCL Commerce existente, los beans de datos que requieren protección ya implementan el control de acceso necesario. Cuando se crean nuevos beans de datos, surge la cuestión sobre qué se ha de proteger. La decisión sobre qué recursos se han de proteger depende de su aplicación. Un bean de datos debe protegerse (directa o indirectamente), si la información que se va a visualizar no está suficientemente protegida por el control de acceso basado en roles de la vista, que corresponde al archivo JSP (Java Server Page) que contiene el bean de datos.

Si un bean de datos se ha de proteger y puede existir por su cuenta, debe protegerse directamente. Si la existencia de un bean de datos depende de la existencia de otro bean de datos, debe delegar la protección al otro bean de datos. Un ejemplo de un bean de datos que debe protegerse directamente es el bean de datos Order. Un ejemplo de un bean de datos que debe protegerse indirectamente es el bean de datos OrderItem, ya que no puede existir sin el bean de datos Order.

Recursos de datos

Los recursos de datos hacen referencia a objetos de negocio que se pueden manipular, como por ejemplo, pedidos, RFQ y usuarios. Generalmente éstos están protegidos a nivel de bean enterprise, pero es posible proteger cualquier clase, a condición de que implemente la interfaz Protectable. Los recursos de datos se protegen utilizando comprobaciones de control de acceso a nivel de recursos. La forma más común de hacer esto es devolviendo recursos de datos en el método getResources() de un mandato de controlador o de tarea.

Grupos de recursos

Un grupo de recursos identifica un conjunto de recursos relacionados. Un grupo de recursos puede incluir objetos de negocio, por ejemplo un contrato o un conjunto de mandatos relacionados. En el control de acceso, los grupos de recursos especifican los recursos a los que la política de control de acceso autoriza el acceso.

Los grupos de recursos se definen en la tabla ACRESGRP. Los Administradores de sitio pueden gestionar grupos de recursos y asociar recursos con grupos de recursos utilizando la Administration Console o utilizando XML.

Grupos de recursos implícitos

Los grupos de recursos implícitos definen recursos que coinciden con un conjunto de atributos determinados. Uno de estos atributos debe ser el nombre de clase Java. Otros atributos pueden ser el estado, el ID de tienda, el precio, etcétera. Por ejemplo, puede crear un grupo de recursos implícito que incluya todos los pedidos que están en estado pendiente (ORDERS.STATUS=P). Los grupos de recursos implícitos se utilizan generalmente para agrupar recursos que se utilizarán en las políticas a nivel de recursos, cuando éstos comparten un atributo común además del nombre de clase Java.

Los grupos de recursos implícitos se definen utilizando la columna CONDITIONS de la tabla ACRESGRP. Se pueden crear grupos de recursos implícitos simples utilizando la Administration Console. Mediante XML se pueden crear grupos cada vez más complejos.

Grupos de recursos explícitos

Los grupos de recursos explícitos se especifican asociando una o varias categorías de recursos a un grupo de recursos. Esta asociación se lleva a cabo en la tabla ACRESGPRES. Si se añade explícitamente una categoría de recursos a un grupo, listando el nombre de clase Java, se pueden agrupar recursos individuales que puede que no compartan necesariamente atributos comunes.

Relaciones

Todos los recursos puede tener algún tipo de relación asociada y un conjunto de miembros que satisfacen esa relación. Por ejemplo, todos los recursos tienen una relación de owner, que la satisface el propietario del recurso. Otras relaciones pueden ser los destinatarios de documentos y el creador de un pedido. Estas relaciones de recursos son importantes para determinar quién puede realizar determinadas acciones en una instancia concreta de un recurso. Por ejemplo, es posible que el creador de un documento no pueda eliminarlo, pero quizá sí lo pueda eliminar un auditor. De forma similar, es posible que un revisor sólo pueda leer y aprobar un documento, pero no enviarlo ni realizar otras operaciones.

Las relaciones se almacenan en la tabla ACRELATION y se especifican opcionalmente en una política de control de acceso mediante la columna ACRELATION_ID de la tabla ACPOLICY. Al evaluar una política que requiere que se cumpla una relación entre el usuario y el recurso, se llamará al método fulfills (Long Member, String relationship) para evaluarlo. Cuando se comparan estas relaciones con los grupos de relaciones, estas relaciones se denominan a veces relaciones simples.

Grupos de relaciones

Las políticas de control de acceso pueden especificar que un usuario debe satisfacer una relación determinada con respecto al recurso al que se está accediendo, o pueden especificar que un usuario debe satisfacer las condiciones especificadas en un grupo de relaciones. En la mayor parte de los casos, una relación es suficiente. Sin embargo, si se necesitan relaciones más complejas, se puede utilizar un grupo de relaciones. Un grupo de relaciones permite especificar varias relaciones y también una cadena de relaciones. Estas dos tareas se pueden realizar utilizando una construcción de cadena de relaciones. Una cadena de relaciones es una construcción que puede expresar una relación sencilla (directamente entre un usuario y el recurso), pero también se puede utilizar para expresar una serie de relaciones entre el usuario y el recurso. Por ejemplo, para poder expresar que un usuario debe tener un rol en una organización que tiene una relación (que no sea la relación de propietario) con el recurso, se debe utilizar un grupo de relaciones. En este ejemplo, hay una relación de rol entre el usuario y la organización y una relación entre la organización y el recurso.

Comparación de relaciones y grupos de relaciones

En la mayor parte de los casos, utilizar una relación es suficiente para satisfacer los requisitos de control de acceso de la aplicación ya que, conceptualmente, la mayor parte de las relaciones son relaciones directas entre un usuario y el recurso. Por ejemplo, la política indica que el usuario debe ser el creador del recurso. Sin embargo, si necesita especificar varias relaciones, debe utilizarse un grupo de relaciones. Por ejemplo, la política indica que el usuario debe ser el creador o el emisor del recurso.

Los grupos de relaciones también se necesitan para expresar una cadena de relaciones entre un usuario y el recurso. En una cadena de relaciones, no hay ninguna relación directa entre el usuario y el recurso, por ejemplo, un usuario pertenece a la organización compradora que especifica un pedido. En este caso, el usuario tiene una relación hijo con la organización y dicha organización tiene una relación de compra con el pedido.

Cadenas de relaciones

<parameter name= "X" value="Y"/>

<openCondition name="RELATIONSHIP_CHAIN">
<parameter name="RELATIONSHIP"
value="aValue"/>
</openCondition>

En las cadenas de relaciones de longitud uno, el elemento <parameter name="Relationship" value="something"> especifica una relación directa entre el usuario y el recurso. El atributo de valor es la serie que representa la relación entre el usuario y el recurso. También debe corresponderse con el parámetro relationship del método fulfills() del recurso protegible.

Cuando una cadena de relaciones tiene una longitud de dos, se trata de una serie de dos relaciones. El primer elemento, <parameter name= "X" value="Y"/>, es entre un usuario y una entidad de organización. El último elemento, <parameter name= "X" value="Y"/>, es entre la entidad de organización y el recurso. A continuación se muestra un ejemplo de una cadena de relaciones con una longitud de dos:

<openCondition name=RELATIONSHIP_CHAIN">
<parameter name="aValue1" value="aValue2"/>
<parameter name="RELATIONSHIP" value="aValue3"/>
</openCondition>

Los aValue1 valores posibles incluyen HIERARCHY y ROLE. HIERARCHY especifica que existe una relación jerárquica entre el usuario y la entidad de organización en la jerarquía de miembros. ROLE especifica que el usuario desempeña un rol en la entidad de organización.

Si el valor de aValue1 es HIERARCHY, los valores posibles son child, que devuelve la entidad de organización de la que el usuario es un elemento secundario directo en la jerarquía de miembros. Si el valor de aValue1 es ROLE, los valores posibles son cualquier entrada válida en la columna NAME de la tabla ROLE, que devuelve todas las entidades de organización para las que el usuario actual tiene ese rol.

La entrada aValue3 es una serie que representa la relación entre una o varias entidades de organización que se recuperan a partir de la evaluación del primer parámetro y el recurso. Este valor se corresponde con el parámetro relationship del método fulfills() del recurso protegible. Si se devuelve más de una entidad de organización al evaluar el parámetro aValue1, esta parte de RELATIONSHIP_CHAIN se satisface si al menos una de estas entidades de organización cumple la relación especificada por el parámetro aValue2.

Tipos de políticas de control de acceso

Hay dos tipos de políticas de control de acceso:

• Políticas estándar agrupables (tipo de política -2)
• Políticas de plantilla agrupables (tipo de política -3)

Tanto las políticas de plantilla agrupables como las políticas estándar agrupables deben pertenecer a un grupo de políticas para aplicarse en el sistema. Una política estándar agrupable se aplica, una sola vez, en las organizaciones que se suscriben a un grupo de políticas que contiene la política.

Las políticas de plantilla agrupables son de naturaleza dinámica en el sentido de que tienen un grupo de acceso que se definen, cuando el sistema está en ejecución, dentro del ámbito de la organización que es propietaria del recurso. Por ejemplo, cuando este tipo de política se aplica a un recurso que es propiedad de la Organización XYZ, comprobará si el usuario desempeña uno de los roles especificados para la Organización XYZ o sus predecesoras.

Políticas de control de acceso predeterminadas especiales

Las políticas siguientes necesitan una descripción adicional:

• Los Administradores de sitio pueden realizar todas las acciones (SiteAdministratorsCanDoEverything)
• El grupo BecomeUserCustomerService ejecuta mandatos BecomeUser en nombre del cliente (BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup)

La política SiteAdministratorsCanDoEverything es una política predeterminada especial que otorga acceso de superusuario a los administradores que tienen el rol de Administrador de sitio. En esta política, un administrador de sitio puede realizar cualquier acción en cualquier recurso, incluso si estas acciones o recursos no se han definido. Es importante recordarlo cuando se asigna este rol a los usuarios.

La política BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup es una política especial que permite que determinados usuarios administrativos ejecuten mandatos especificados en nombre de otros usuarios. Esta política es necesaria cuando, por ejemplo, un cliente solicita un representante del servicio al cliente para que cree un pedido en su nombre. En este caso, el representante de servicio al cliente puede ejecutar el mandato de modo que parezca que el propio cliente ha ejecutado el mandato.