Interacciones del control de acceso

La infraestructura de políticas de control de accesos controla cómo funciona el control de acceso en HCL Commerce.

El diagrama de sintaxis siguiente muestra las interacciones de las políticas de control de acceso. En el diagrama siguiente se describen los detalles.

Este diagrama muestra las interacciones de políticas de control de acceso.

El diagrama anterior muestra las acciones que realiza el control de acceso policy manager. El gestor de políticas de control de acceso es el componente de control de acceso que determina si al usuario actual se le permite ejecutar la acción especificada en el recurso indicado. Determina el acceso buscando en las políticas de los grupos a los que está suscrito el propietario del recurso. Si el propietario del recurso no está suscrito a ningún grupo de políticas, busca en las políticas de los grupos a los que está suscrito el predecesor más cercano del propietario del recurso. Si al menos una política otorga acceso, el permiso se otorga.

La lista siguiente describe las acciones del diagrama de interacciones anterior. Están ordenadas de arriba a abajo.

isGeneric()
Determina si un usuario genérico debe convertirse en un usuario invitado. Si el usuario actual es genérico, la conversión a un usuario invitado tiene lugar antes de invocar cualquiera de los métodos restantes.
setRequestProperties()
Pasa los parámetros de solicitud al mandato. Los parámetros de solicitud se pueden utilizar en llamadas de control de acceso posteriores (por ejemplo, devolviendo datos específicos de parámetro de solicitud de getOwner() o getResources()).
isAllowed() [nivel-mandato]
Los componentes de ejecución determinan si el usuario tiene acceso de nivel de mandato para la vista o el mandato de controlador.
Nota: Los parámetros para un mandato de controlador se fijan para el ID del usuario actual, la serie de acción Execute y la clase de recurso. La clase de recurso es la clase de implementación totalmente calificada para el mandato de controlador.
getOwner() [nivel-mandato]
El gestor de políticas de control de acceso determina el propietario del recurso a nivel de mandato. La implementación predeterminada devuelve el identificador de miembros (memberId) del propietario de la tienda (storeId) que está en el contexto del mandato. Si no hay ningún identificador de tienda en el contexto del mandato, se devuelve la organización raíz (-2001). Puede devolver otros valores que tengan sentido desde la perspectiva de la propiedad en el control de acceso a nivel de mandato para el mandato.
getAndApplyApplicablePolicies() [nivel-mandato]
El Gestor de políticas de control de acceso busca y procesa las políticas aplicables, basándose en el usuario, la acción y el recurso especificados, y la tienda actual. Si una política comporta un rol, y usted especifica una tienda, el gestor de políticas evalúa si el usuario actual tiene el rol especificado en la organización de tienda especificada. Cuando una política comporta un rol, y usted no especifica una tienda, el gestor de políticas evalúa si el usuario actual tiene el rol especificado en alguna organización. Si como mínimo una política aplicable otorga el acceso, se pasa la comprobación de acceso a nivel de mandato y el gestor de políticas continúa en el siguiente paso para empezar a comprobar la autorización a nivel de recurso. A la inversa, si ninguna de las políticas aplicables otorga acceso a nivel de mandato, el gestor de políticas vuelve y rechaza el acceso.
validateParameters()
Comprueba y resuelve los parámetros iniciales.
Nota: Dado que se llama a este método después del control de acceso a nivel de mandato, pero antes de la llamada getResources(), puede utilizarse la lógica de validateParameters() para resolver los datos utilizados en getResources().
getResources()
Devuelve un vector de acceso que es un vector de parejas recurso-acción.

Si no se devuelve nada, la comprobación de control de acceso a nivel de recurso no se efectúa. Si hay recursos que deban protegerse, debe devolverse un vector de acceso (consistente en parejas recurso-acción).

Cada resource es una instancia de un objeto protegible (un objeto que implementa la interfaz com.ibm.commerce.security.Protectable). En muchos casos, el recurso es un bean de acceso.

Un bean de acceso no puede implementar la interfaz com.ibm.commerce.security.Protectable; sin embargo, la comprobación de control de acceso todavía puede ocurrir si el enterprise bean correspondiente esté protegido, según la información que se incluye en Implementar el control de acceso en enterprise beans.

La action es una serie que representa la operación que se va a efectuar en el recurso. En la mayoría de casos, la acción es el nombre de interfaz del mandato, que se presupone si no se ha especificado ninguna acción al añadir recursos al vector.

isAllowed() [nivel-recurso]
Los componentes de ejecución determinan si el usuario tiene acceso a nivel de recurso a todas las parejas recurso-acción especificadas por getResources().
getOwner() [nivel-recurso]
El recurso devuelve el memberId de su propietario. El memberID determina las políticas que se aplican.
getAndApplyApplicablePolicies() [nivel-recurso]
El gestor de políticas de control de acceso busca las políticas aplicables y, a continuación, las aplica. Si como mínimo se encuentra una política por pareja recurso-acción que otorgue permiso al usuario para acceder al recurso, se otorga el acceso. De lo contrario, se deniega el acceso.
fulfils()
Si una política aplicable tiene especificada una relación o un grupo de relaciones, se realiza una comprobación en el recurso para ver si el miembro satisface la relación especificada respecto al recurso.
performExecute()
La lógica de negocio del mandato.
isRetriable()
Comprueba si el mandato puede intentarse de nuevo en caso de una excepción ECSystemException generada mediante la llamada performExecute().