Autorización de cliente de aplicaciones

La autorización del cliente de aplicaciones consta de clases de permisos de ObjectGrid, mecanismos de autorización, un periodo de comprobación de permisos y un acceso sólo por parte de la autorización del creador.

Para eXtreme Scale, la autorización se basa en el objeto Subject y los permisos. El producto soporta dos tipos de mecanismos de autorización: Java Authentication and Authorization Service (JAAS) y la autorización personalizado.

Clases de permiso de ObjectGrid

La autorización se basa en permisos. Existen cuatro tipos diferentes de clases de permiso del modo siguiente.
  • La clase MapPermission representa permisos para acceder a los datos de las correlaciones ObjectGrid.
  • La clase ObjectGridPermission representa permisos para acceder a ObjectGrid.
  • La clase ServerMapPermission representa permisos para acceder a las correlaciones ObjectGrid en el lado del servidor desde un cliente.
  • La clase AgentPermission representa permisos para iniciar un agente en el lado del servidor.
Para obtener más información, consulte Programación de autorización de cliente.

Período de comprobación de permisos

eXtreme Scale soporta el almacenamiento en memoria caché de los resultados de la comprobación de permisos de correlación con finalidades de rendimiento. Sin este mecanismo, cuando se llama a un método que está en la lista de métodos para la clase de permiso en particular, el tiempo de ejecución llama al mecanismo de autorización configurado para autorizar el acceso. Con este período de comprobación de permisos establecido, el mecanismo de autorización se llama periódicamente en función del período de comprobación de permisos.Para ver una lista de métodos para cada clase de permiso, consulte Programación de autorización de cliente.

La información de autorización de permisos se basa en el objeto Subject. Cuando un cliente intenta acceder a los métodos, el tiempo de ejecución de eXtreme Scale consulta la memoria caché en función del objeto Subject. Si el objeto no se encuentra en la memoria caché, el tiempo de ejecución comprueba los permisos concedidos para este objeto Subject, y luego almacena los permisos en una memoria caché.

El período de comprobación de permisos debe definirse antes de inicializar ObjectGrid. El período de comprobación de permisos puede configurarse de dos modos:

Puede utilizar el archivo XML de ObjectGrid para definir un ObjectGrid y establecer el periodo de comprobación de permisos. En el siguiente ejemplo, el periodo de comprobación de permisos se establece en 45 segundos:
<objectGrids>
	<objectGrid name="secureClusterObjectGrid" securityEnabled="true"
	authorizationMechanism="AUTHORIZATION_MECHANISM_JAAS" 
	permissionCheckPeriod="45">
		<bean id="bean id="TransactionCallback"
className="com.ibm.websphere.samples.objectgrid.HeapTransactionCallback" />
...
</objectGrids>
Si desea crear un ObjectGrid con API, llame al siguiente método para establecer el periodo de comprobación de permisos. Este método sólo puede llamarse antes de inicializar la instanciel ObjectGrid. Este método se aplica sólo al modelo de programación local de eXtreme Scale cuando cree una instancia directamente de ObjectGrid.
/**
 * Este método toma un único parámetro que indica con qué frecuencia
 * desea comprobar el permiso utilizado para permitir un acceso de cliente. Si el
 * parámetro es 0 cada llamada única get/put/update/remove/evict
 * solicita al mecanismo de autorización, autorización JAAS o personalizada,
 * comprobar si el objeto Subject actual tiene permiso. Esto podría ser
 * muy costoso desde el punto de vista del rendimiento en función de
 * la implementación de autorización, pero si necesita comprobar el
 * mecanismo de autorización, establezca el parámetro en 0.
 * De forma alternativa, si el parámetro es > 0, indica el número
 * de segundos que tarda en almacenar en la memoria caché un conjunto de
permisos antes de volver al
 * mecanismo de autorización para que los actualice. Este valor proporciona un
 * mejor rendimiento, pero si los permisos del programa de fondo
 * se cambian durante este tiempo, ObjectGrid puede
 * permitir o denegar el acceso aunque el proveedor de seguridad
 * del programa de fondo se haya modificado.
 * 
 * @param period periodo de comprobación de servicio en segundos.
 */
void setPermissionCheckPeriod(int period);

Autorización de sólo acceso de creador

La autorización de sólo acceso de creador garantiza que sólo el usuario (representado por los objetos Principal asociados a él) que inserta la entrada en la correlación ObjectGrid pueda acceder (leer, actualizar, invalidar y eliminar) a la entrada.

El modelo de autorización de la correlación ObjectGrid existente se basa en el tipo de acceso, no en las entradas de datos. En otras palabras, un usuario tiene un tipo determinado de acceso (leer, grabar, insertar, suprimir o invalidar) para todos los datos de la correlación o para ninguno. No obstante, eXtreme Scale no autoriza a los usuarios la entrada individual de los datos. Esta característica ofrece una nueva manera de autorizar a los usuarios las entradas de datos.

En un escenario donde diferentes usuarios pueden acceder a distintos conjuntos de datos, este modelo puede ser de utilidad. Cuando el usuario carga los datos del almacén persistente en las correlaciones ObjectGrid, el acceso puede autorizarse desde el almacén persistente. En este caso, no es necesario realizar otra autorización en la capa de correlación ObjectGrid. Sólo debe asegurarse de que la persona que carga los datos en la correlación pueda acceder a ella mediante la habilitación de la característica de sólo acceso de creador.

Valores del atributo modalidad de sólo creador:
disabled
La característica de sólo acceso de creador está inhabilitada.
complement
La característica de sólo acceso de creador está habilitada para complementar la autorización de correlaciones. En otras palabras, la autorización de correlaciones y, también, la característica de sólo acceso de creador entran en vigor. Por lo tanto, puede limitar las operaciones a los datos. Por ejemplo, el creador no puede invalidar los datos.
supersede
La característica de sólo acceso de creador está habilitada para reemplazar la autorización de correlaciones. En otras palabras, la característica de sólo acceso de creador reemplaza la autorización de correlaciones; no se produce ninguna autorización de correlaciones.

Puede configurar esta característica de dos modos:

Mediante un archivo XML:

Puede utilizar el archivo XML de ObjectGrid para definir un ObjectGrid y establecer la modalidad de sólo acceso de creador en disabled, complement o supersede, tal como se indica en el siguiente ejemplo:
<objectGrids>
    <objectGrid name="secureClusterObjectGrid" securityEnabled="true"	
	        accessByCreatorOnlyMode="supersede"
        <bean id="TransactionCallback"
              classname="com.ibm.websphere.samples.objectgrid.HeapTransactionCallback" />
    ...
</objectGrids>

A través de programa:

Si desea crear un ObjectGrid mediante programa, puede llamar al siguiente método para establecer la modalidad de sólo acceso de creador. La llamada a este método sólo se aplica al modelo de programación de eXtreme Scale local cuando se crea directamente una instancia de ObjectGrid:
/**
 * Establezca la modalidad de sólo acceso de creador.
 * Si habilita esta modalidad se asegura de que sólo el usuario (representado
 * por los principales asociados a éste), que inserta el registro en la correlación,
 * pueda acceder (leer, actualizar, invalidar y eliminar) al registro.
 * La modalidad de sólo acceso de creador puede inhabilitarse, o puede complementar
 * el modelo de autorización ObjectGrid, o puede reemplazar el modelo de autorización
 * ObjectGrid. El valor predeterminado es la modalidad inhabilitada:
 * {@link SecurityConstants#ACCESS_BY_CREATOR_ONLY_DISABLED}.
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_DISABLED
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_COMPLEMENT
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_SUPERSEDE
 *
 * @param accessByCreatorOnlyMode acceso mediante la modalidad de creador.
 *
 * @since WAS XD 6.1 FIX3
*/
void setAccessByCreatorOnlyMode(int accessByCreatorOnlyMode);
Con el propósito de ilustrar con más detalle, considere un escenario en el que una cuenta de correlaciones de ObjectGrid está en una cuadrícula de banca, y Manager1 y Employee1 son los dos usuarios. La política de autorización de eXtreme Scale otorga todos los permisos de acceso a Manager1, pero sólo otorga un permiso de acceso de lectura a Employee1. La política JAAS para la autorización de correlación ObjectGrid se muestra en el siguiente ejemplo:
grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
    Principal com.acme.PrincipalImpl "Manager1" {
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "banking.account", "all"
};
grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
    Principal com.acme.PrincipalImpl "Employee1" {
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "banking.account", "read, insert"
};
Considere cómo la modalidad de sólo acceso de creador afecta a la autorización:
  • disabled Si la característica de sólo acceso de creador está inhabilitada, la autorización de correlaciones no cambia. El usuario "Manager1" puede acceder a todos los datos de la correlación de cuenta "account". El usuario "Employee1" puede leer e insertar todos los datos de la correlación pero no puede actualizarlos, invalidarlos ni eliminar ningún dato de la correlación.
  • complement Si la característica de sólo acceso de creador está habilitada con la opción complementaria "complement", entrarán en vigor la autorización de correlaciones y la autorización de sólo acceso de creador. El usuario "Manager1" puede acceder a los datos de la correlación de cuenta "account", pero sólo si el usuario los ha cargado en la correlación. El usuario "Employee1" puede leer los datos de la correlación de cuenta "account", pero sólo si ese usuario los ha cargado en la correlación. No obstante, este usuario no puede actualizar, invalidar ni eliminar ningún dato en la correlación.
  • supersede Si la característica de sólo acceso de creador está habilitada con la opción de reemplazar "supersede", no se aplicará la autorización de correlaciones. La autorización de sólo acceso de creador será la única política de autorización. El usuario "Manager1" tiene el mismo privilegio que en la modalidad "complement": este usuario puede acceder a los datos de la correlación de cuenta "account" sólo si ese mismo usuario ha cargado los datos en la correlación. No obstante, el usuario "Employee1" ahora tiene acceso completo a los datos de la correlación "account" si este usuario los ha cargado en la correlación. En otras palabras, la política de autorización definida en la política JAAS (Java Authentication and Authorization Service) no se aplicará.