Implementar el control de acceso en los mandatos de controlador

En el caso de las políticas de control de acceso a nivel de mandato para los mandatos de controlador, el nombre de interfaz del mandato se especifica como un recurso. Para que un recurso esté protegido, debe implementar la interfaz Protectable. De acuerdo con el modelo de programación de HCL Commerce, esto se consigue ampliando la interfaz del mandato a partir de la interfaz com.ibm.commerce.command.ControllerCommand y ampliando la implementación del mandato a partir de com.ibm.commerce.command.ControllerCommandImpl. La interfaz ControllerCommand se amplía a partir de la interfaz com.ibm.commerce.command.AccCommand que, a su vez, se amplía a partir de la interfaz Protectable. La interfaz AccCommand es la interfaz mínima que debe implementar un mandato para estar protegido mediante el control de acceso a nivel de mandato.

Si el mandato accede a recursos que deben protegerse, cree una variable de instancia privada del tipo AccessVector para que contenga los recursos. A continuación, altere el método getResources dado que la implementación predeterminada de este método devuelve un valor nulo y, por consiguiente, no se produce ninguna comprobación de recursos.

En el nuevo método getResources, debe devolver un conjunto de recursos o de pares de recurso-acción sobre los que el mandato puede actuar. Cuando una acción no se especifica de forma explícita, la acción toma el valor predeterminado del nombre de interfaz del mandato que se ejecuta.

Solo es necesario especificar la acción cuando un mandato está realizando una operación de lectura y otra de grabación en instancias diferentes de la misma clase de recurso. Por ejemplo, en el caso del mandato OrderCopy, puede leer en un pedido de origen y grabar en un pedido de destino. En este caso, se debe realizar una diferenciación entre las dos acciones. Esto se logra especificando la acción "-Read" para el pedido de origen y la acción "-Write" para el pedido de destino. Cuando la infraestructura de control de acceso detecta estas acciones, las añade automáticamente al principio con el nombre de interfaz del mandato antes de buscar las políticas aplicables. En este caso, las acciones que se utilizarán finalmente en las políticas son "com.ibm.commerce.order.commands.OrderCopyCmd-Read" y "com.ibm.commerce.order.commands.OrderCopyCmd-Write".

Adicionalmente, se recomienda que el método determine si debe crear una instancia del recurso o si puede utilizar la variable de instancia existente que contiene la referencia al recurso. La comprobación de si el objeto de recurso ya existe puede ayudar a mejorar el rendimiento del sistema. Entonces, si es necesario, puede utilizar la misma variable de instancia en el método performExecute del nuevo mandato de controlador.

Para determinar si debe alterar el método getResources, tenga en cuenta lo siguiente:

• Si obtiene el recurso basándose en una fuente predefinida de información, por ejemplo el contexto de mandato, no necesitará alterar el método getResources. Por ejemplo, el mandato de HCL Commerce UserRegistrationUpdate obtiene el ID del usuario del contexto de mandato. En este caso, el usuario ya está autorizado a actuar en su propia información de registro, de modo que no es necesario alterar el método getResources.
• Si el mandato está especificando de forma arbitraria un recurso nuevo (y este recurso es de naturaleza privada), deberá alterar el método getResources. Por ejemplo, el mandato de HCL Commerce OrderItemUpdate toma un ID de pedido como parámetro de entrada. En este caso, cuando se cree la instancia de recurso de pedido, no sabrá si el usuario tiene autorización para realizar acciones en ese recurso en particular. En este caso, se altera el método getResources.

A continuación se muestra un ejemplo del método getResources:

private AccessVector resources = null;

public AccessVector getResources() throws ECException { 

 if (resources == null) {
  OrderAccessBean orderAB = new OrderAccessBean(); 
  orderAB.setInitKey_orderId(getOrderId().toString()); 
  resources = new AccessVector(orderAB); 
  }
 return resources;
}

Tomemos, como ejemplo, el mandato OrderItemUpdate. El método getResources de este mandato devuelve uno o más objetos de pedido (que son protegibles), cuando está actualizando los pedidos existentes. Dado que no se especifica la acción, la acción toma de forma predeterminada la interfaz para el mandato OrderItemUpdate.

El método getResources puede devolver diversos recursos. Cuando esto sucede, para poder llevar a cabo la acción debe encontrarse una política que ofrezca acceso al usuario a todos los recursos especificados. Si un usuario tiene acceso a dos de tres recursos, la acción no podrá continuar (es necesario tener acceso a los tres).

Si tiene que efectuar comprobación adicional de parámetros o resolución de parámetros en el mandato de controlador, puede utilizar el método validateParameters(). La utilización de este método es opcional.

Comprobación adicional a nivel de recurso

No siempre es posible determinar todos los recursos que necesitan protegerse, en el momento en que se llama al método getResources del mandato de controlador.

Si fuera necesario, un mandato de tarea puede también implementar un método getResources para devolver una lista de recursos, en los que puede actuar el mandato.

Otra manera de invocar la comprobación a nivel de recurso es realizar llamadas directas al gestor de políticas de control de acceso, utilizando el método checkIsAllowed(Object resource, String action). Este método está disponible para cualquier clase que se amplíe a partir de la clase com.ibm.commerce.command.AbstractECTargetableCommand. Por ejemplo, la siguiente clase se amplía desde la clase AbstractECTargetableCommand:

• com.ibm.commerce.command.ControllerCommandImpl
• com.ibm.commerce.command.DataBeanCommandImpl

El método checkIsAllowed también está disponible para las clases que amplían la clase com.ibm.commerce.command.AbstractECCommand. Por ejemplo, la siguiente clase se amplía desde la clase AbstractECCommand:

• com.ibm.commerce.command.TaskCommandImpl

A continuación se muestra la firma del método checkIsAllowed:

void checkIsAllowed(Object resource, String action) 
 throws ECException

Este método emite una excepción ECApplicationException si el usuario actual no tiene permiso para efectuar la acción especificada en el recurso especificado. Si se otorga el acceso, el método simplemente regresa.

Control de acceso para los mandatos "create"

Puesto que se llama al método getResources antes que al método performExecute en un mandato, debe tomarse otro enfoque para el control de acceso de recursos que todavía no se han creado. Por ejemplo, si tiene un WidgetAddCmd, el método getResources no puede devolver el recurso que se va a crear. En este caso, el método getResources debe devolver el contenedor del nuevo recurso. Por ejemplo, si se está creando un pedido, esto se realiza dentro del recurso de tienda y se crea un nuevo usuario dentro de un recurso de organización.

Implementaciones predeterminadas para el control de acceso a nivel de mandato

Para el control de acceso a nivel de mandato, la implementación predeterminada del método getOwner() devuelve el memberId del propietario de la tienda, si se especifica el storeId. Si no se especifica el storeId, se devuelve el memberId de la organización raíz (memberId = -2001).

La implementación predeterminada del método getResources() devuelve null.

La implementación predeterminada de validateParameters() no hace nada.