See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in with your developerWorks ID, you can leave comments and feedback for the development team.

Use this topic to learn about the ObjectGrid client authorization mechanism.

ObjectGrid client server security has the following important aspects:

ObjectGrid authorization is based on the Subject object and permissions. ObjectGrid supports two kinds of authorization mechanisms: Java Authentication and Authorization Service (JAAS) authorization and custom authorization.

ObjectGrid Permission classes

Authorization is based on permissions. There are different kinds of ObjectGrid authorization represented by five different Permission classes :

1. MapPermission. This permission represents permissions to access the data in ObjectGrid maps.
2. ObjectGridPermission. This permission represents permissions to access ObjectGrid.
3. ServerMapPermission. This permission represents permissions to access ObjectGrid maps on the server side from a client.
4. AgentPermission. This permission represents permissions to start an agent on the server side.
5. AdminPermission. This permission represents permissions for different management tasks.

MapPermission

In ObjectGrid, the com.ibm.websphere.objectgrid.security.MapPermission public class represents permissions to the ObjectGrid resources, specifically the methods of ObjectMap or JavaMap interfaces. ObjectGrid defines the following permission strings to access the methods of ObjectMap and JavaMap:

1. read: permission to read the data from the map. The integer constant is defined as MapPermission.READ
2. write: permission to update the data in the map. The integer constant is defined as MapPermission.WRITE.
3. insert: permission to insert the data into the map. The integer constant is defined as MapPermission.INSERT.
4. remove: permission to remove the data from the map. The integer constant is defined as MapPermission.REMOVE.
5. invalidate: permission to invalidate the data from the map. The integer constant is defined as MapPermission.INVALIDATE.
6. all: all above permissions: read, write, insert, remote, and invalidate. The integer constant is defined as MapPermission.ALL.

Refer to MapPermission API Documentation for more details.

You can construct a MapPermission object by passing the fully qualified ObjectGrid map name (in format [ObjectGrid_name].[ObjectMap_name]) and the permission string or integer value. A permission string can be a comma-delimited string of the previous permissions strings such as read, insert, or it can be all which means all permissions are granted. A permission integer value can be any previously mentioned permission integer constants or a mathematical or value of several integer permission constants, such as MapPermission.READ|MapPermission.WRITE.

The authorization occurs when an ObjectMap or JavaMap method being called. The ObjectGrid run time checks different permissions for different methods. If the required permissions are not granted to the client, an AccessControlException exception results.

Table 1. List of methods and the required MapPermission

Authorization is based solely on which method is used, rahter than what the method really does. For example, a put method can insert or update a record based on whether the record exists. However, the insert or update cases are not distinguished.

An operation type can be achieved by combinations of other types. For example, an update can be achieved by a remove and then an insert. Consider these combinations when designing your authorization policies.

ObjectGridPermission

A com.ibm.websphere.objectgrid.security.ObjectGridPermission represents permissions to the ObjectGrid. It has three different actions:

1. query: permission to create an object query or entity query. The integer constant is defined as ObjectGridPermission.QUERY.
2. streamquery: permission to deploy or undeploy a stream query. The integer constant is defined as ObjectGridPermission.STREAM_QUERY.
3. all: all above permissions.

Refer to ObjectGridPermission API Documentation for more details.

The following table summarizes the methods and the required ObjectGridPermission:

Table 2. List of methods and the required ObjectGridPermission

ServerMapPermission

An ServerMapPermissionrepresents permissions to an ObjectMap hosted in a server. The name of the permission is the full name of the ObjectGrid map name. It has three actions:

1. replicate: permission to replicate a server map to near cache.
2. dynamicIndex: permission for a client to create or remove a dynamic index on server

Refer to ServerMapPermission API Documentation for more details.

The detailed methods, which require different ServerMapPermission, are listed in the following table:

Table 3. List of methods and the required ObjectGridPermission

AgentPermission

An AgentPermission represents permissions to the datagrid agents. The name of the permission is the full name of the ObjectGrid map, and the action is a "," delimited string of agent implementation class names or package names.

Refer to AgentPermission API Documentation for more details.

The following methods in the class com.ibm.websphere.objectgrid.datagrid.AgentManager requires AgentPermission:

• com.ibm.websphere.objectgrid.datagrid.AgentManager#callMapAgent(MapGridAgent, Collection)
• com.ibm.websphere.objectgrid.datagrid.AgentManager#callMapAgent(MapGridAgent)
• com.ibm.websphere.objectgrid.datagrid.AgentManager#callReduceAgent(ReduceGridAgent, Collection)
• com.ibm.websphere.objectgrid.datagrid.AgentManager#callReduceAgent(ReduceGridAgent, Collection)

AdminPermission

The administration permission is represented by the com.ibm.websphere.objectgrid.security.AdminPermission class. ObjectGrid defines two permission actions for administration permissions:

1. admin: Grant permissions to do any administration tasks.
2. monitor: Grant permissions to actions that are read-access-only administration tasks.

Refer to AdminPermission API Documentation for more details.

The detailed operations that are granted to users with different permissions are listed in the following table. These operations correspond to the methods in the ManagementMBean interface:

Table 4. Relationship between management tasks and administration permissions

If the client has admin permission, it can run the startServer task; if the client has monitor permission, it cannot run the startServer task.

Authorization mechanisms

ObjectGrid supports two kinds of authorization mechanisms: Java Authentication and Authorization Service (JAAS) authorization and custom authorization. These mechanisms apply to all authorizations. JAAS authorization augments the Java security policies with user-centric access controls. Permissions can be granted based not just on what code is running, but also on who is running it. JAAS authorization is part of the SDK Version 1.4 and later.

ObjectGrid also supports custom authorization with the following plug-ins:

1. MapAuthorization: custom way to authorization accesses to maps. As of WebSphere Extended Depployment server 6.1, this interface is deprecated. ObjectGridAuthorization is recommended to use.
2. ObjectGridAuthorization: custom way to authorize access to all ObjectGrid artifacts.
3. AdminAuthorization: custom way to authorize management tasks.

You can implement your own authorization mechanism if you do not want to use JAAS authorization. By using a custom authorization mechanism, you can use the policy database, policy server, or Tivoli Access Manager to manage the ObjectGrid authorizations.

You can configure the ObjectGrid authorization mechanism in two ways:

1. Configuration. You can use the ObjectGrid XML file to define an ObjectGrid and set the authorization mechanism to either AUTHORIZATION_MECHANISM_JAAS or AUTHORIZATION_MECHANISM_CUSTOM. Here is the secure-objectgrid-definition.xml file that is used in the ObjectGridSample enterprise application sample:

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

2. Programming. If you want to create an ObjectGrid using method ObjectGrid.setAuthorizationMechanism(int), you can call the following method to set the authorization mechanism. Calling this method applies only to the local ObjectGrid programming model when you directly instantiate the ObjectGrid instance:

   /**
    * Set the authorization Mechanism. The default is 
    * com.ibm.websphere.objectgrid.security.SecurityConstants.
    * AUTHORIZATION_MECHANISM_JAAS.
    * @param authMechanism the map authorization mechanism
   */
   void setAuthorizationMechanism(int authMechanism);

JAAS authorization

A javax.security.auth.Subject object represents an authenticated user. A Subject is comprised of a set of principals, and each Principal represents an identity for that user. For example, a Subject can have a name principal, for example, Joe Smith, and a group principal, for example, manager.

Using the JAAS authorization policy, permissions can be granted to specific Principals. ObjectGrid associates the Subject with the current access control context. For each call to the ObjectMap or Javamap method, the Java run time automatically determines if the policy grants the required permission only to a specific Principal and if so, the operation is allowed only if the Subject associated with the access control context contains the designated Principal.

You must be familiar with the policy syntax of the policy file. For detailed description of JAAS authorization, refer to the JAAS Reference Guide.

ObjectGrid has a special code base that is used for checking the JAAS authorization to the ObjectMap and JavaMap method calls. This special code base is http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction. Use this code base when granting ObjectMap or JavaMap permissions to principals. This special code was created because the Java archive (JAR) file for ObjectGrid is granted with all permissions.

The template of the policy to grant the MapPermission permission is:

grant codeBase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
   <Principal field(s)>{
    permission com.ibm.websphere.objectgrid.security.MapPermission 
               "[ObjectGrid_name].[ObjectMap_name]", "action";
    ....
    permission com.ibm.websphere.objectgrid.security.MapPermission 
               "[ObjectGrid_name].[ObjectMap_name]", "action";
  };

A Principal field looks like the following example:

principal Principal_class "principal_name"

The word principal is followed by the fully qualified name of a Principal class and a principal name. The map_name is the fully qualified map name in the format [ObjectGrid Name].[Map Name], for example, secureClusterObjectGrid.employees. The action is a comma-delimited string of the permissions strings, defined in MapPermission class, such as read, insert, or all.
Limited wildcard function is supported. You can replace the ObjectGrid name or map name with an asterisk * to indicate any. However, ObjectGrid does not support replacing part of the ObjectGrid name or map name with an asterisk . Therefore, *.employees, clusterObjectGrid.*, and *.* are all valid names, but cluster.employees is not valid.

For example, in the ObjectGridSample.ear sample application, two authorization policy files are defined: fullAccessAuth.policy and readInsertAccessAuth.policy. The content of the readInsertAccessAuth.policy file follows:

grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
    Principal com.ibm.ws.security.common.auth.WSPrincipalImpl 
			"principal_name" {
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "secureClusterObjectGrid.employees", "read,insert";
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "secureClusterObjectGrid.offices", "read,insert";
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "secureClusterObjectGrid.sites", "read,insert";
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "secureClusterObjectGrid.counters", "read,insert";
};

In this policy, only insert and read permissions are granted to these four maps to a certain principal. The other policy file, fullAccessAuth.policy, grants all permissions to these maps to a principal. Before running the application, change the principal_name and principal class to appropriate values. The value of the principal_name depends on the user registry. For example, if local OS is used as user registry, the machine name is MACH1, the user ID is user1, and the principal_name is MACH1/user1.

The JAAS authorization policy can be put directly into the Java policy file, or it can be put in a separate JAAS authorization file and then set by using the

-Djava.security.auth.policy=file:[JAAS_AUTH_POLICY_FILE]

-Dauth.poliyc.url.x=file:[JAAS_AUTH_POLICY_FILE]

Custom map authorization

ObjectGrid also supports the custom map authorization by the MapAuthorization plug-in. As of XD 6.1, MapAuthorization is deprecated and replaced by ObjectGridAuthorization. However, the way to implement MapAuthorization and ObjectGridAuthorization is the same.

Refer to MapAuthorization API Documentation for more details.

This plug-in can be used to authorize ObjectMap and JavaMap accesses to the principals that are contained in the Subject object. The boolean checkPermission(Subject subject, MapPermission permission) method of the MapAuthorization interface is called by the ObjectGrid run time to check whether the passed-in subject object has the passed-in map permission. The implementation of the MapAuthorization interface returns true if the object has the permission, and false if not.

A typical implementation of this plug-in is to retrieve the principals from the Subject object and check whether the specified permissions are granted to the principals by consulting specific policies. These policies are defined by users. For example, the policies can be defined in a database, a plain file, or a Tivoli Access Manager policy server.

ObjectGrid provides two default implementations for this plug-in. The com.ibm.websphere.objectgrid.security.plugins.builtins. JAASMapAuthorizationImpl class is an implementation of MapAuthorization interface that uses the JAAS mechanism for authorization. Another implementation class is the com.ibm.websphere.objectgrid.security.plugins.builtins. TAMMapAuthorizationImpl class. It shows how Tivoli Access Manager can be used to manage the ObjectGrid authorizations. The following code snippet shows the basic flow of the JAASMapAuthorizationImpl.checkPermission(Subject, MapPermission):

// Creates a PrivilegedExceptionAction to check the permssions.
PrivilegedExceptionAction action = 
	MapPermissionCheckAction.getInstance(permission);

Subject.doAsPrivileged(subject, action, null);

See the IBM Tivoli Access Manager Authorization Java Classes Developer Reference for more details.

Use this TAMMapAuthorizationImpl plug-in for testing purposes only because of its certain restrictive preconditions:

1. The Subject object contains a com.tivoli.mts.PDPrincipal principal.
2. The Tivoli Access Manager policy server has defined the following permissions for the ObjectMap or JavaMap name object. The object that is defined in the policy server must have the same name as the ObjectMap or JavaMap name in the format of [ObjectGrid_name].[ObjectMap_name]. The permission is the first character of the permission strings that are defined in the MapPermission permission. For example, the permission "r" that is defined in the policy server represents the read permission to the ObjectMap map.

The following code snippet demonstrates how to implement the checkPermission method:

/**
* @see com.ibm.websphere.objectgrid.security.plugins.
* 		MapAuthorization#checkPermission
* (javax.security.auth.Subject, com.ibm.websphere.objectgrid.security.
* 		MapPermission)
*/
public boolean checkPermission(final Subject subject, 
	MapPermission permission) {
  
  String[] str = permission.getParsedNames();
  
  StringBuffer pdPermissionStr = new StringBuffer(5); 
  for (int i=0; i<str.length; i++) {
    pdPermissionStr.append(str[i].substring(0,1));
  }
  
  PDPermission pdPerm = new PDPermission(permission.getName(), 
		pdPermissionStr.toString());
  
  Set principals = subject.getPrincipals();
  
  Iterator iter= principals.iterator(); 
  while(iter.hasNext()) {
    try {
      PDPrincipal principal = (PDPrincipal) iter.next();
      if (principal.implies(pdPerm)) {
        return true;
      }
    }
    catch (ClassCastException cce) {
      // Handle exception
    }
  }
  return false;
}

The MapAuthorization plug-in can be configured in the following ways:

1. Configuration. You can use the ObjectGrid XML file to define a MapAuthorization plug-in. Here is an example:

   <objectGrids>
   	<objectGrid name="secureClusterObjectGrid" securityEnabled="true"
   		authorizationMechanism="AUTHORIZATION_MECHANISM_CUSTOM">
   ...
   		<bean id="MapAuthorization"
   className="com.ibm.websphere.objectgrid.security.plugins.builtins.
   JAASMapAuthorizationImpl" />
   </objectGrids>

2. Programming. If you want to create an ObjectGrid using API method ObjectGrid.setMapAuthorization(MapAuthorization), you can call the following method to set the authorization plug-in. This method only applies to the local ObjectGrid programming model when you directly instantiate the ObjectGrid instance.

   /**
   * Sets the MapAuthorization plug-in for this ObjectGrid instance. 
   * 
   * A {@link MapAuthorization} plug-in can be used to authorize
   * access to the maps. Refer to {@link MapAuthorization} 
   * for more details.
   * @param mapAuthorization the MapAuthorization plug-in 
   */
   void setMapAuthorization(MapAuthorization mapAuthorization);

Custom ObjectGrid authorization

ObjectGridAuthorization plug-in is used to authorize ObjectGrid, ObjectMap and JavaMap accesses to the Principals represented by a Subject object in a custom way. A typical implementation of this plug-in is to retrieve the Principals from the Subject object, and then check whether or not the specified permissions are granted to the Principals.

A permission passed to the checkPermission(Subject, Permission) method could be one of the following.:

1. MapPermission
2. ObjectGridPermission
3. AgentPermission
4. ServerMapPermission

Refer to ObjectGridAuthorization API Documentation for more details.

As described above, the MapAuthorization is deprecated in WebSphere Extended Deployment server 6.1. We recommend you implement ObjectGridAuthorization to check the whether a Subject should be granted with a MapPermission or not.

We do not provide any built-in implementation for ObjectGridAuthorization. However, the description for implementing a MapAuthorization should give you an idea of how to implement an ObjectGridAuthorization plug-in.

The ObjectGridAuthorization plug-in can be configured in the following ways:

1. Configuration. You can use the ObjectGrid XML file to define a ObjectAuthorization plug-in. Here is an example:

   <objectGrids>
   	<objectGrid name="secureClusterObjectGrid" securityEnabled="true"
   		authorizationMechanism="AUTHORIZATION_MECHANISM_CUSTOM">
   ...
   		<bean id="ObjectGridAuthorization"
   className="com.acme.ObjectGridAuthorizationImpl" />
   </objectGrids>

2. Programming. If you want to create an ObjectGrid using API method ObjectGrid.setObjectGridAuthorization(ObjectGridAuthorization), you can call the following method to set the authorization plug-in. This method only applies to the local ObjectGrid programming model when you directly instantiate the ObjectGrid instance.

   /**
        * Sets the <code>ObjectGridAuthorization</code> for this ObjectGrid instance. 
        * <p>
        * Passing <code>null</code> to this method removes a previously set 
        * <code>ObjectGridAuthorization</code> object from an earlier invocation of this method
        * and indicates that this <code>ObjectGrid</code> is not associated with a
        * <code>ObjectGridAuthorization</code> object.
        * <p>
        * This method should only be used when ObjectGrid security is enabled. If 
        * the ObjectGrid security is disabled, the provided <code>ObjectGridAuthorization</code> object 
        * will not be used.
        * <p>
        * A <code>ObjectGridAuthorization</code> plugin can be used to authorize
        * access to the ObjectGrid and maps. Please refer to <code>ObjectGridAuthorization</code> for more details.
        *    
        * <p>
        * As of XD 6.1, the <code>setMapAuthorization</code> is deprecated and 
        * <code>setObjectGridAuthorization</code> is recommended for use. However, 
        * if both <code>MapAuthorization</code> plugin and <code>ObjectGridAuthorization</code> plugin 
        * are used, ObjectGrid will use the provided <code>MapAuthorization</code> to authorize map accesses,
        * even though it is deprecated.
        * <p>
        * Note, to avoid an <code>IllegalStateException</code>, this method must be
        * called prior to the <code>initialize()</code> method.  Also, keep in mind 
        * that the <code>getSession</code> methods implicitly call the 
        * <code>initialize()</code> method if it has yet to be called by the 
        * application.
        * 
        * @param ogAuthorization the <code>ObjectGridAuthorization</code> plugin 
        * 
        * @throws IllegalStateException if this method is called after the 
        *         <code>initialize()</code> method is called.
        * 
        * @see #initialize()
        * @see ObjectGridAuthorization    
        * @since WAS XD 6.1     
        */
       void setObjectGridAuthorization(ObjectGridAuthorization ogAuthorization);

Custom administration authorization

Like the custom map data access authorization support, ObjectGrid supports the custom administration authorization. Refer to AdminAuthorization API Documentation for more details.

Use this plug-in to authorize admin accesses to the principals that are contained in the Subject object. The method:
boolean checkPermission(Subject subject, AdminPermission permission)in the AdminAuthorization interface is called by the ObjectGrid run time to check whether the passed-in Subject object has the passed-in admin permission. The implementation of the AdminAuthorization interface returns true if yes and false if no.

You can implement this interface based on your security requirements. ObjectGrid does not ship an implementation class for this interface.

You can set the AdminAuthorization plug-in on the cluster level in the cluster XML. An example follows:

<cluster name="cluster1" securityEnabled="true"
	singleSignOnEnabled="true" loginSessionExpirationTime="300" 
	statisticsEnabled="true"
	statisticsSpec="map.all=enabled">
	<serverDefinition name="server1" host="localhost" 
		clientAccessPort="12503" peerAccessPort="12500" workingDirectory=""
		traceSpec="ObjectGrid=all=disabled"
		systemStreamToFileEnabled="true" />
	<serverDefinition name="server2" host="localhost" 
		clientAccessPort="12504" peerAccessPort="12501" workingDirectory=""
		traceSpec="ObjectGrid=all=disabled"
		systemStreamToFileEnabled="true" />
	<authenticator className ="com.ibm.websphere.objectgrid.security.plugins.
		builtins.WSTokenAuthenticator"></authenticator>
	<adminAuthorization className= "com.ibm.ws.objectgrid.test.security.util.
		TestAdminAuthorization"></adminAuthorization>
</cluster>

Permission checking period

ObjectGrid 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 ObjectGrid run time calls the configured authorization mechanism to authorize the 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 ObjectGrid run time looks up the cache based on the Subject object. If the object cannot be found in the cache, the run time 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:

1. Configuration. You can use the ObjectGrid XML file to define an ObjectGrid and set the permission check period. Here is an example to set the permission check period 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>

2. Programming. If you want 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 ObjectGrid 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 have 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, we cannot authorize users to individual data entry. This new feature offers a new way to authorize users to data entries.

In a scenario where different users access different set 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. We just need to ensure only 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 mode:

1. disabled. In this mode, the access by creator only feature is disabled.
2. complement. In this mode, 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 will take effect. Therefore, you can further limit the operations to the data. For example, the creator cannot invalidate the data.
3. supersede. In this mode, the access by creator only feature is enabled to supersede the map authorization. In other words, the access by creator only feature will supersede the map authorization; no map authorization will be done.

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

1. Configuration. 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". Here is an example sample:

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

1. Programming. If you want 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 ObjectGrid programming model when you directly instantiate the ObjectGrid instance:

   /**
        * Set the "access by creator only" mode.
        * <p>
        * 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.
        * <p>
        * 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}.
        * <p>
        * @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);

An example

Suppose we have an ObjectGrid map account in the banking grid. There are two users "Manager1" and "Employee1". Assume the ObjectGrid authorization policy grant all access permissions to "Manager1", but only read access permission to "Employee1".

Here is the JAAS policy for the ObjectGrid map authorization.

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

Now lets take a look how the access by creator only feature will affect the 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 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 if and only he/she loaded them into the map. The user "Employee1" can read the data in the "account" map if and only he/she loaded them into the map, but cannot update/invalidate/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: he/she can access the data in the "account" map if he/she loaded them into the map. However, the user "Employee1" now has full access to the data in the "account" map if he/she loaded them into the map. In other words, the authorization policy defined in the Java Authentication and Authorization Service (JAAS) policy is not enforced.

Wiki Disclaimer and License

© Copyright IBM Corporation 2007,2009. All Rights Reserved.