Authorizing administrative clients

Through administrative security, you can authorize users to access the data grid. Certain conditions are required, depending on your WebSphere® eXtreme Scale installation environment and the users that you want to have access.

1. Configure authorization for xscmd operations and the stopOgServer command.
   If you use the following command to access the data grid, you might also be authorized to perform administrative actions, such as running the listAllJMXAddresses command:

   ./xscmd.sh -user <user> -password <password> <other_parameters>

   If the user can run the previous command, then any xscmd operation or the stopOgServer command might also be performed by the same user.

   When eXtreme Scale components run with WebSphere Application Server, use the WebSphere Application Server administrative console to activate the security manager. To restrict application access to local resources, click Security > Global Security, and select the check boxes, Enable administrative security and Use Java 2 Security, to restrict application access to local resources.

   Access to the management operations is controlled by the WebSphere Application Server security manager and is granted only to the users who belong to the WebSphere Administrator role. You must run the xscmd command and the stopOgServer command from the WebSphere Application Server directory.

2. Configure administrative authorization in stand-alone installations.

   When eXtreme Scale components run in a stand-alone environment, more steps are required to implement administrative security. You must run the catalog servers and container servers using the Java™ security manager, which requires a policy file.

   The policy file resembles the following example:

   Remember: The policy file also typically contains MapPermission entries, as documented in Java SE security tutorial - Step 5.

   grant codeBase "file:${objectgrid.home}/-" {
   permission java.security.AllPermission;
   };
   
   grant principal javax.security.auth.x500.X500Principal "CN=manager,O=acme,OU=OGSample"
        {
           permission javax.management.MBeanPermission "*", 
   "getAttribute,setAttribute,invoke,queryNames,addNotificationListener,removeNotificationListener";
        };

   If the client is a Java Spring application, the following AgentPermission entry is needed in policy file, to allow the CN=manager account to access the data grid from the Spring client.

   grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction"
   principal javax.security.auth.x500.X500Principal "CN=manager,O=acme,OU=OGSample" {
   permission com.ibm.websphere.objectgrid.security.AgentPermission "*.*", 
   "com.ibm.ws.objectgrid.spring.PutAgent";
   };

   If the client is a dynamic cache application, the following AgentPermission entry is needed in the policy file, to allow the CN=manager account to access the data grid from the dynamic cache client.

   grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
   (http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction%27)
       principal javax.security.auth.x500.X500Principal "CN=manager,O=acme,OU=OGSample" {
       permission com.ibm.websphere.objectgrid.security.AgentPermission "DYNACACHE_REMOTE.*", 
         "com.ibm.ws.objectgrid.dynacache.agents.*";
   };

   If you configuring authorization security in a Multi-Master Replication (MMR) environment, then all catalog and container servers must run with the following policy in the og_auth.config file:

   grant {
     permission java.net.SocketPermission "localhost", "resolve";
     permission java.lang.RuntimePermission "accessDeclaredMembers";
   };
   

   In this example, only the manager principal is authorized for administrative operations with the xscmd command or the stopOgServer command. You can add other lines as necessary to give more principals MBean permissions. A different type of principal is needed if you use LDAP authentication.

   Enter the following command. If you are using IBM eXtremeIO, use the startXsServer command:

   startOgServer.sh <arguments> -jvmargs -Djava.security.auth.login.config=jaas.config 
   -Djava.security.manager -Djava.security.policy="auth.policy" -Dobjectgrid.home=$OBJECTGRID_HOME

   

   startXsServer.sh <arguments> -jvmargs -Djava.security.auth.login.config=jaas.config 
   -Djava.security.manager -Djava.security.policy="auth.policy" -Dobjectgrid.home=$OBJECTGRID_HOME

   

   startOgServer.bat <arguments> -jvmargs -Djava.security.auth.login.config=jaas.config 
   -Djava.security.manager -Djava.security.policy="auth.policy" -Dobjectgrid.home=%OBJCTGRID_HOME%

   

   startXsServer.bat <arguments> -jvmargs -Djava.security.auth.login.config=jaas.config
    -Djava.security.manager -Djava.security.policy="auth.policy" -Dobjectgrid.home=%OBJCTGRID_HOME%