WebSphere eXtreme Scale Administration Guide > Secure the deployment environment



Application client authorization


Application client authorization consists of ObjectGrid permission classes, authorization mechanisms, a permission checking period, and access by creator only authorization.

For eXtreme Scale, authorization is based on the Subject object and permissions. The product supports two kinds of authorization mechanisms: Java™ Authentication and Authorization Service (JAAS) and custom authorization.


ObjectGrid permission classes

Authorization is based on permissions. There are four different types of permission classes as follows.

For more information, see Client authorization programming.


Permission checking period

eXtreme Scale supports caching the map permission checking results for performance reasons. Without this mechanism, when a method listed on List of methods and their required permissions is called, the runtime calls the configured authorization mechanism to authorize access. With this permission checking period set, the authorization mechanism is called periodically based on the permission checking period.

The permission authorization information is based on the Subject object. When a client tries to access the methods, the eXtreme Scale runtime looks up the cache based on the Subject object. If the object cannot be found in the cache, the runtime checks the permissions granted for this Subject object, and then stores the permissions in a cache.

The permission checking period must be defined before the ObjectGrid is initialized. The permission checking period can be configured in two ways:

You can use the ObjectGrid XML file to define an ObjectGrid and set the permission check period. In the following example, the permission check period is set to 45 seconds: 

<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>

To create an ObjectGrid with APIs, call the following method to set the permission checking period. This method can be called only before the ObjectGrid instance is initialized. This method applies only to the local eXtreme Scale programming model when you instantiate the ObjectGrid instance directly. 

/**
 * This method takes a single parameter indicating how often you 
 * want to check the permission used to allow a client access. If the 
 * parameter is 0 then every single get/put/update/remove/evict call  
 * asks the authorization mechanism, either JAAS authorization or custom 
 * authorization, to check if the current subject has permission. This might be 
 * prohibitively expensive from a performance point of view depending on 
 * the authorization implementation, but if you need to have ever call check the 
 * authorization mechanism, then set the parameter to 0. 
 * Alternatively, if the parameter is > 0 then it indicates the number 
 * of seconds to cache a set of permissions before returning to 
 * the authorization mechanism to refresh them. This value provides much 
 * better performance, but if the back-end 
 * permissions are changed during this time then the ObjectGrid can 
 * allow or prevent access even though the back-end security 
 * provider was modified.
 * 
 * @param period the permission check period in seconds.
 */
void setPermissionCheckPeriod(int period);


Access by creator only authorization

Access by creator only authorization ensures that only the user (represented by the Principal objects associated with it) who inserts the entry into the ObjectGrid map can access (read, update, invalidate and remove) that entry.

The existing ObjectGrid map authorization model is based on the access type but not data entries. In other words, a user has a particular type of access, such as read, write, insert, delete, or invalidate, to either all the data in the map or none of the data. However, eXtreme Scale does not authorize users for individual data entry. This feature offers a new way to authorize users to data entries.

In a scenario where different users access different sets of data, this model can be useful. When the user loads data from the persistent store into the ObjectGrid maps, the access can be authorized by the persistent store. In this case, there is no need to do another authorization in the ObjectGrid map layer. You need only ensure that the person who loads the data into the map can access it by enabling the access by creator only feature.

There are three different access by creator only modes:

disabled

The access by creator only feature is disabled.

complement

The access by creator only feature is enabled to complement the map authorization. In other words, both map authorization and access by creator only feature takes effect. Therefore, you can further limit the operations to the data. For example, the creator cannot invalidate the data.

supersede

The access by creator only feature is enabled to supersede the map authorization. In other words, the access by creator only feature supersedes the map authorization; no map authorization occurs.

You can configure the access by creator only mode in two ways:

You can use the ObjectGrid XML file to define an ObjectGrid and set the access by creator only mode to either disabled, complement, or supersede, as shown in the following example: 

<objectGrids>
   
<objectGrid name="secureClusterObjectGrid" securityEnabled="true"    
            accessByCreatorOnlyMode="supersede"
       
<bean id="TransactionCallback"
              classname="com.ibm.websphere.samples.objectgrid.HeapTransactionCallback" />
    ...
</objectGrids>

To create an ObjectGrid programmatically, you can call the following method to set the access by creator only mode. Calling this method applies only to the local eXtreme Scale programming model when you directly instantiate the ObjectGrid instance: 

/**
 * Set the "access by creator only" mode.
 * Enabling "access by creator only" mode ensures that only the user (represented
 * by the Principals associated with it), who inserts the record into the map,
 * can access (read, update, invalidate, and remove) the record.
 * The "access by creator only" mode can be disabled, or can complement the
 * ObjectGrid authorization model, or it can supersede the ObjectGrid
 * authorization model. The default value is disabled:
 * {@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 the access by creator mode.
 *
 * @since WAS XD 6.1 FIX3
*/
void setAccessByCreatorOnlyMode(int accessByCreatorOnlyMode);

To further illustrate, consider a scenario in which an ObjectGrid map account is in a banking grid, and Manager1 and Employee1 are the two users. The eXtreme Scale authorization policy grants all access permissions to Manager1, but only read access permission to Employee1. The JAAS policy for the ObjectGrid map authorization is shown the following example: 

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"
};

Consider how the access by creator only feature affects authorization:



Parent topic

Secure the deployment environment


+

Search Tips   |   Advanced Search