Application client authorization

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.

The MapPermission class represents permissions to access the data in ObjectGrid maps.

The ObjectGridPermission class represents permissions to access ObjectGrid.

The ServerMapPermission class represents permissions to access ObjectGrid maps on the server side from a client.

The AgentPermission class represents permissions to start an agent on the server side.

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 that is listed in the listed in list of methods that for the particular permission class 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. For a list of methods for each permission class, see Client authorization programming.
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:
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  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.

Creator only mode attribute values:

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:

By XML file:
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>
Programmatically:
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:

disabled If the access by creator only feature is disabled, the map authorization is no different. The user "Manager1" can access all the data in the "account" map. The user "Employee1" can read and insert all the data in the map but cannot update, invalidate, remove any data in the map.

complement If the access by creator only feature is enabled with "complement" option, both the map authorization and access by creator only authorization will take effect. The user "Manager1" can access the data in the "account" map, but only if the user alone loaded them into the map. The user "Employee1" can read the data in the "account" map, but only if that user alone loaded them into the map. (However, this user cannot update, invalidate, or remove any data in the map.)

supersede If the access by creator only feature is enabled with "supersede" option, the map authorization will not be enforced. The access by creator only authorization will be the only authorization policy. The user "Manager1" has the same privilege as in the "complement" mode: this user can access the data in the "account" map only if the same user loaded the data into the map. However, the user "Employee1" now has full access to the data in the "account" map if this user loaded them into the map. In other words, the authorization policy defined in the Java Authentication and Authorization Service (JAAS) policy will then not be enforced.

Parent topic:
Secure the deployment environment

Related concepts

Security integration with WAS
Data grid authentication
Data grid security
Application client authentication
Transport layer security and secure sockets layer
Java Management Extensions (JMX) security
Security integration with external providers

Related tasks

Enable local security
Start and stop secure servers
Secure the REST data service

Related reference

Security descriptor XML file
objectGridSecurity.xsd file

Related information

Tutorial: Integrate WebSphere eXtreme Scale security with WAS
Tutorial: Integrate WebSphere eXtreme Scale security in a mixed environment with an external authenticator

+
Search Tips | Advanced Search