After authenticating a client, as in the previous step, you can give security privileges through eXtreme Scale authorization mechanisms.

1. Enable eXtreme Scale authorization. To enable authorization on the ObjectGrid, you need to set the securityEnabled attribute to true for that particular ObjectGrid in the XML file. Enabling security on the ObjectGrid means that you are enabling authorization. Use the following commands to create a new ObjectGrid XML file with security enabled.
   1. Navigate to the xml directory.

      cd objectgridRoot/xml

   2. Copy the SimpleApp.xml file to the SecureSimpleApp.xml file.

      cp SimpleApp.xml SecureSimpleApp.xml

   3. Open the SecureSimpleApp.xml file and add securityEnabled="true" on the ObjectGrid level as the following XML shows:

      <?xml version="1.0" encoding="UTF-8"?> <objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"  		 xmlns="http://ibm.com/ws/objectgrid/config">     <objectGrids>         <objectGrid name="accounting" securityEnabled="true">             <backingMap name="customer" readOnly="false" copyKey="true"/>         </objectGrid>     </objectGrids> </objectGridConfig>

2. Define the authorization policy.
   In the pre-client authentication section, you created three users in the key store: cashier, manager, and administrator. In this example, the user "cashier" only has read permissions to all the maps, and the user "manager" has all permissions. JAAS authorization is used in this example. JAAS authorization uses authorization policy file to grant permissions to principals. The following file is defined in the security directory:

   grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction"     principal javax.security.auth.x500.X500Principal "CN=cashier,O=acme,OU=OGSample" {     permission com.ibm.websphere.objectgrid.security.MapPermission "accounting.*", "read "; };  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.MapPermission "accounting.*", "all"; };

   Note:
   • The codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" is a specially-reserved URL for ObjectGrid. All ObjectGrid permissions granted to principals should use this special code base.
   • The first grant statement grants "read" map permission to principal "CN=cashier,O=acme,OU=OGSample", so the cashier has only map read permission to all the maps in the ObjectGrid accounting.
   • The second grant statement grants "all" map permission to principal "CN=manager,O=acme,OU=OGSample", so the manager has all permissions to maps in the ObjectGrid accounting.
   Now you can launch a server with an authorization policy. The JAAS authorization policy file can be set using the standard -D property: -Djava.security.auth.policy=../security/ogAuth.policy
3. Run the application.
   

   After you create the above files, you can run the application.

   Use the following commands to start the catalog server. For more information about starting the catalog service, see Starting the catalog service in a stand-alone environment.

   1. Navigate to the bin directory: cd objectgridRoot/bin
   2. Start the catalog server.
      • startOgServer.sh catalogServer -clusterSecurityFile ../security/security.xml -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"
      • startOgServer.bat catalogServer -clusterSecurityFile ../security/security.xml -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"

      The security.xml and server.properties files were created in the previous step of this tutorial.

      T

   3. You can then start a secure container server using the following script. Run the following script from the bin directory:
      • # startOgServer.sh c0 -objectGridFile ../xml/SecureSimpleApp.xml -deploymentPolicyFile ../xml/SimpleDP.xml -catalogServiceEndPoints localhost:2809 -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config" -Djava.security.auth.policy="../security/og_auth.policy"
      • startOgServer.bat c0 -objectGridFile ../xml/SecureSimpleApp.xml -deploymentPolicyFile ../xml/SimpleDP.xml -catalogServiceEndPoints localhost:2809 -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config" -Djava.security.auth.policy="../security/og_auth.policy"
   Notice the following differences from the previous container server start command:

   • Use the SecureSimpleApp.xml file instead of the SimpleApp.xml file.
   • Add another -Djava.security.auth.policy argument to set the JAAS authorization policy file to the container server process.
   Use the same command as in the previous step of the tutorial:

   1. Navigate to the bin directory.
   2. java -classpath ../lib/objectgrid.jar;../applib/secsample.jar com.ibm.websphere.objectgrid.security.sample.guide.SecureSimpleApp ../security/client.properties manager manager1

      Because user "manager" has all permissions to maps in the accounting ObjectGrid, the application runs properly.

      Now, instead of using user "manager", use user "cashier" to launch the client application.

   3. Navigate to the bin directory.
   4. java -classpath ../lib/objectgrid.jar;../applib/secsample.jar com.ibm.ws.objectgrid.security.sample.guide.SecureSimpleApp ../security/client.properties cashier cashier1

   The following exception results:

   Exception in thread "P=387313:O=0:CT" com.ibm.websphere.objectgrid.TransactionException:  rolling back transaction, see caused by exception 	at com.ibm.ws.objectgrid.SessionImpl.rollbackPMapChanges(SessionImpl.java:1422)  	at com.ibm.ws.objectgrid.SessionImpl.commit(SessionImpl.java:1149)  	at com.ibm.ws.objectgrid.SessionImpl.mapPostInvoke(SessionImpl.java:2260)  	at com.ibm.ws.objectgrid.ObjectMapImpl.update(ObjectMapImpl.java:1062)  	at com.ibm.ws.objectgrid.security.sample.guide.SimpleApp.run(SimpleApp.java:42) 	at com.ibm.ws.objectgrid.security.sample.guide.SecureSimpleApp.main(SecureSimpleApp.java:27) Caused by: com.ibm.websphere.objectgrid.ClientServerTransactionCallbackException:     Client Services - received exception from remote server:      com.ibm.websphere.objectgrid.TransactionException: transaction rolled back,  			see caused by Throwable         at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.processReadWriteResponse(             RemoteTransactionCallbackImpl.java:1399)         at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.processReadWriteRequestAndResponse(             RemoteTransactionCallbackImpl.java:2333)         at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.commit(RemoteTransactionCallbackImpl.java:557)         at com.ibm.ws.objectgrid.SessionImpl.commit(SessionImpl.java:1079)         ... 4 more Caused by: com.ibm.websphere.objectgrid.TransactionException: transaction rolled back, see caused by Throwable         at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processLogSequence(ServerCoreEventProcessor.java:1133)         at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processReadWriteTransactionRequest 					(ServerCoreEventProcessor.java:910)         at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processClientServerRequest(ServerCoreEventProcessor.java:1285)          at com.ibm.ws.objectgrid.ShardImpl.processMessage(ShardImpl.java:515)         at com.ibm.ws.objectgrid.partition.IDLShardPOA._invoke(IDLShardPOA.java:154)         at com.ibm.CORBA.poa.POAServerDelegate.dispatchToServant(POAServerDelegate.java:396)         at com.ibm.CORBA.poa.POAServerDelegate.internalDispatch(POAServerDelegate.java:331)         at com.ibm.CORBA.poa.POAServerDelegate.dispatch(POAServerDelegate.java:253)         at com.ibm.rmi.iiop.ORB.process(ORB.java:503)         at com.ibm.CORBA.iiop.ORB.process(ORB.java:1553)         at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2680)         at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2554)         at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)         at com.ibm.rmi.iiop.WorkerThread.run(ThreadPoolImpl.java:202)         at java.lang.Thread.run(Thread.java:803) Caused by: java.security.AccessControlException: Access denied (    com.ibm.websphere.objectgrid.security.MapPermission accounting.customer write)         at java.security.AccessControlContext.checkPermission(AccessControlContext.java:155)         at com.ibm.ws.objectgrid.security.MapPermissionCheckAction.run(MapPermissionCheckAction.java:141)         at java.security.AccessController.doPrivileged(AccessController.java:275)         at javax.security.auth.Subject.doAsPrivileged(Subject.java:727)         at com.ibm.ws.objectgrid.security.MapAuthorizer$1.run(MapAuthorizer.java:76)         at java.security.AccessController.doPrivileged(AccessController.java:242)         at com.ibm.ws.objectgrid.security.MapAuthorizer.check(MapAuthorizer.java:66)         at com.ibm.ws.objectgrid.security.SecuredObjectMapImpl.checkMapAuthorization(SecuredObjectMapImpl.java:429)         at com.ibm.ws.objectgrid.security.SecuredObjectMapImpl.update(SecuredObjectMapImpl.java:490)         at com.ibm.ws.objectgrid.SessionImpl.processLogSequence(SessionImpl.java:1913)         at com.ibm.ws.objectgrid.SessionImpl.processLogSequence(SessionImpl.java:1805)         at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processLogSequence(ServerCoreEventProcessor.java:1011)         ... 14 more

   This exception occurs because the user "cashier" does not have write permission, so it cannot update the map customer.

   Now your system supports authorization. You can define authorization policies to grant different permissions to different users. For more information about authorization, see Application client authorization.

This topic describes a simple unsecured sample. Additional security features are added incrementally in the steps of the tutorial to increase the amount of integrated security that is available.

For more information about starting container servers, see Starting container processes.

The output of this program is:

The customer name for ID 0001 is fName lName

Stopping servers

Container server

Use the following command to stop the container server c0.

stopOgServer.sh c0 -catalogServiceEndPoints localhost:2809

stopOgServer.bat c0 -catalogServiceEndPoints localhost:2809

You will see the following message.

CWOBJ2512I: ObjectGrid server c0 stopped.

Catalog server

You can stop a catalog server using the following command.

stopOgServer.sh catalogServer -catalogServiceEndPoints localhost:2809

stopOgServer.bat catalogServer -catalogServiceEndPoints localhost:2809

If you shut down the catalog server, you will see the following message.

CWOBJ2512I: ObjectGrid server catalogServer stopped.

The file below is the Java class for SimpleApp.

SimpleApp.java // This sample program is provided AS IS and may be used, executed, copied and modified  // without royalty payment by customer  // (a) for its own instruction and study,  // (b) in order to develop applications designed to run with an IBM WebSphere product,  // either for customer's own internal use or for redistribution by customer, as part of such an  // application, in customer's own products. // Licensed Materials - Property of IBM // 5724-J34 (C) COPYRIGHT International Business Machines Corp. 2007-2009 package com.ibm.websphere.objectgrid.security.sample.guide;  import com.ibm.websphere.objectgrid.ClientClusterContext; import com.ibm.websphere.objectgrid.ObjectGrid; import com.ibm.websphere.objectgrid.ObjectGridManager; import com.ibm.websphere.objectgrid.ObjectGridManagerFactory; import com.ibm.websphere.objectgrid.ObjectMap; import com.ibm.websphere.objectgrid.Session;  public class SimpleApp {      public static void main(String[] args) throws Exception {          SimpleApp app = new SimpleApp();         app.run(args);     }      /**      * read and write the map       * @throws Exception      */     protected void run(String[] args) throws Exception {         ObjectGrid og = getObjectGrid(args);          Session session = og.getSession();          ObjectMap customerMap = session.getMap("customer");          String customer = (String) customerMap.get("0001");          if (customer == null) {             customerMap.insert("0001", "fName lName");         } else {             customerMap.update("0001", "fName lName");         }         customer = (String) customerMap.get("0001");          System.out.println("The customer name for ID 0001 is " + customer);     }      /**      * Get the ObjectGrid      * @return an ObjectGrid instance      * @throws Exception      */     protected ObjectGrid getObjectGrid(String[] args) throws Exception {         ObjectGridManager ogManager = ObjectGridManagerFactory.getObjectGridManager();          // Create an ObjectGrid          ClientClusterContext ccContext = ogManager.connect("localhost:2809", null, null);         ObjectGrid og = ogManager.getObjectGrid(ccContext, "accounting");          return og;      }  }

The getObjectGrid method in this class obtains an ObjectGrid, and the run method reads a record from the customer map and updates the value.

To run this sample in a distributed environment, an ObjectGrid descriptor XML file SimpleApp.xml, and a deployment XML file, SimpleDP.xml, are created. The files are featured in the following example:

SimpleApp.xml  <?xml version="1.0" encoding="UTF-8"?> <objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  	xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"  	xmlns="http://ibm.com/ws/objectgrid/config">     <objectGrids>         <objectGrid name="accounting">             <backingMap name="customer" readOnly="false" copyKey="true"/>         </objectGrid>     </objectGrids> </objectGridConfig> 

The following XML file configures the deployment environment.

SimpleDP.xml  <?xml version="1.0" encoding="UTF-8"?> <deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 	xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd" 	xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">  	<objectgridDeployment objectgridName="accounting"> 		<mapSet name="mapSet1" numberOfPartitions="1" minSyncReplicas="0" maxSyncReplicas="2"  			maxAsyncReplicas="1"> 			<map ref="customer"/> 		</mapSet> 	</objectgridDeployment> </deploymentPolicy>

This is a simple ObjectGrid configuration with one ObjectGrid instance named "accounting" and one map named "customer" (within the mapSet "mapSet1"). The SimpleDP.xml file features one map set that is configured with 1 partition and 0 minimum required replicas.

Building on the previous step, the following topic shows how to implement client authentication in a distributed eXtreme Scale environment.

1. Client credential
   

   A client credential is represented by a com.ibm.websphere.objectgrid.security.plugins.Credential interface. A client credential can be a user name and password pair, a Kerberos ticket, a client certificate, or data in any format that the client and server agree upon. Refer to Credential API documentation for more details.

   This interface explicitly defines the equals(Object) and hashCode() methods. These two methods are important because the authenticated Subject objects are cached by using the Credential object as the key on the server side.

   eXtreme Scale also provides a plug-in to generate a credential. This plug-in is represented by the com.ibm.websphere.objectgrid.security.plugins.CredentialGenerator interface, and is used to generate a client credential. This is useful when the credential is expirable. In this case, the getCredential() method is called to renew a credential. Refer to CredentialGenerator API Documentation for more details.

   You can implement these two interfaces for eXtreme Scale client runtime to obtain client credentials.

   This sample uses the following two sample plug-in implementations provided by eXtreme Scale.

   com.ibm.websphere.objectgrid.security.plugins.builtins.UserPasswordCredential

   com.ibm.websphere.objectgrid.security.plugins.builtins.UserPasswordCredentialGenerator 

   For more information about these plug-ins, see Client authentication programming

2. Server authenticator
   After the eXtreme Scale client retrieves the Credential object using the CredentialGenerator object, this client Credential object is sent along with the client request to the eXtreme Scale server. The eXtreme Scale server authenticates the Credential object before processing the request. If the Credential object is authenticated successfully, a Subject object is returned to represent this client.

   This Subject object is then cached, and it expires after its lifetime reaches the session timeout value. The login session timeout value can be set by using the loginSessionExpirationTime property in the cluster XML file. For example, setting loginSessionExpirationTime="300" makes the Subject object expire in 300 seconds.

   This Subject object is then used for authorizing the request, which is shown later.

   An eXtreme Scale server uses the Authenticator plug-in to authenticate the Credential object. Refer to Authenticator API Documentation for more details.

   This example uses an eXtreme Scale built-in implementation: KeyStoreLoginAuthenticator, which is for testing and sample purposes (a key store is a simple user registry and should not be used for production). For more information, see the topic on authenticator plug-in under Client authentication programming.

   This KeyStoreLoginAuthenticator uses a KeyStoreLoginModule to authenticate the user with the key store by using the JAAS login module "KeyStoreLogin". The key store can be configured as an option to the KeyStoreLoginModule class. The following example illustrates the keyStoreLogin alias configured in the JAAS configuration file og_jaas.config:

   KeyStoreLogin{ com.ibm.websphere.objectgrid.security.plugins.builtins.KeyStoreLoginModule required      keyStoreFile="../security/sampleKS.jks" debug = true; };

   The following commands create a key store sampleKS.jks in the %OBJECTGRID_HOME%/security directory with the password as sampleKS1. Also, three user certificates representing the administrator user, the manager user, and the cashier user are created with their own passwords.

   1. Navigate to the eXtreme Scale root directory.

      cd objectgridRoot

   2. Create a directory called "security".

      mkdir security

   3. Navigate to the newly created security directory.

      cd security

   4. Use keytool (in the javaHOME/bin directory) to create a user "administator" with password "administrator1" in the key store sampleKS.jks.

      keytool -genkey -v -keystore ./sampleKS.jks -storepass sampleKS1  -alias administrator -keypass administrator1  -dname CN=administrator,O=acme,OU=OGSample -validity 10000

   5. Use keytool (in the javaHOME/bin directory) to create a user "manager" with password "manager1" in the key store sampleKS.jks.

      keytool -genkey -v -keystore ./sampleKS.jks -storepass sampleKS1  -alias manager -keypass manager1  -dname CN=manager,O=acme,OU=OGSample -validity 10000

   6. Use keytool (in the javaHOME/bin directory) to create a user "cashier" with password "cashier1" in the key store sampleKS.jks.

      keytool -genkey -v -keystore ./sampleKS.jks -storepass sampleKS1  -alias cashier -keypass cashier1 -dname CN=cashier,O=acme,OU=OGSample  -validity 10000

   The client security configuration is configured in the client properties file. Use the following command to create a copy in the %OBJECTGRID_HOME%/security directory:

   1. Change to the security directory.

      cd objectgridRoot/security

   2. Copy the sampleClient.properties file to the client.properties file.

      cp ../properties/sampleClient.properties client.properties

   The following properties are highlighted in the client.properties file in the security directory.

   1. securityEnabled: Setting securityEnabled to true (default value) enables the client security, which includes authentication.
   2. credentialAuthentication: Set credentialAuthentication to Supported (default value), which means the client supports credential authentication.
   3. transportType: Set transportType to TCP/IP, which means no SSL will be used.
   4. singleSignOnEnabled: Set it to false (default value). Single sign-on is not available.
3. Server security configuration
   

   The server security configuration is specified in the security descriptor XML file and the server security property file.

   The security descriptor XML file describes the security properties common to all servers (including catalog servers and container servers). One property example is the authenticator configuration which represents the user registry and authentication mechanism.

   Here is the security.xml file to be used in this sample:

   <?xml version="1.0" encoding="UTF-8"?> <securityConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"      xsi:schemaLocation="http://ibm.com/ws/objectgrid/config/security ../objectGridSecurity.xsd" 	xmlns="http://ibm.com/ws/objectgrid/config/security">  	<security securityEnabled="true" loginSessionExpirationTime="300" >                  <authenticator className ="com.ibm.websphere.objectgrid.security.plugins.builtins.	 					KeyStoreLoginAuthenticator">         </authenticator>     </security> 	 </securityConfig>

   1. securityEnabled: Set to true, which enables the server security including authentication.
   2. loginSessionExpirationTime: Set the value to 300 (default value).
   3. authenticator: Add the authenticator class KeyStoreLoginAuthenticator to the cluster XML file as follows:

      <authenticator className ="com.ibm.websphere.objectgrid.security.plugins.builtins.KeyStoreLoginAuthenticator">         </authenticator>

   4. credentialAuthentication: Set credentialAuthentication attribute to Required so the server requires authentication

   For more detailed explanation on the security.xml file, see Security descriptor XML file.

   Copy the server properties file into the security directory. At this time, you do not need to modify anything in this file.

   1. Navigate to the security directory.

      cd objectgridRoot/security

   2. Copy the sample objectGrid sampleServer.properties file from the properties directory to the new server.properties file.

      cp ../properties/containerServer.properties server.properties

   Make the following changes in the server.properties file:

   1. securityEnabled: Set the securityEnabled attribute to true.
   2. transportType: Set transportType attribute to TCP/IP, which means no SSL is used.
   3. secureTokenManagerType: Set secureTokenManagerType attribute to none to not configure the secure token manager.
4. Secure client
   Connect the client application to the server securely as demonstrated in the following example:

   package com.ibm.websphere.objectgrid.security.sample.guide;  import com.ibm.websphere.objectgrid.ClientClusterContext; import com.ibm.websphere.objectgrid.ObjectGrid; import com.ibm.websphere.objectgrid.ObjectGridManager; import com.ibm.websphere.objectgrid.ObjectGridManagerFactory; import com.ibm.websphere.objectgrid.security.config.ClientSecurityConfiguration; import com.ibm.websphere.objectgrid.security.config.ClientSecurityConfigurationFactory; import com.ibm.websphere.objectgrid.security.plugins.CredentialGenerator; import com.ibm.websphere.objectgrid.security.plugins.builtins.UserPasswordCredentialGenerator;  public class SecureSimpleApp extends SimpleApp {      public static void main(String[] args) throws Exception {          SecureSimpleApp app = new SecureSimpleApp();         app.run(args);     }      /**      * Get the ObjectGrid      * @return an ObjectGrid instance      * @throws Exception      */     protected ObjectGrid getObjectGrid(String[] args) throws Exception {         ObjectGridManager ogManager = ObjectGridManagerFactory.getObjectGridManager();         ogManager.setTraceFileName("logs/client.log");         ogManager.setTraceSpecification("ObjectGrid*=all=enabled:ORBRas=all=enabled");          // Creates a ClientSecurityConfiguration object using the specified file         ClientSecurityConfiguration clientSC = ClientSecurityConfigurationFactory                 .getClientSecurityConfiguration(args[0]);                  // Creates a CredentialGenerator using the passed-in user and password.         CredentialGenerator credGen = new UserPasswordCredentialGenerator(args[1], args[2]);         clientSC.setCredentialGenerator(credGen);                  // Create an ObjectGrid by connecting to the catalog server          ClientClusterContext ccContext = ogManager.connect("localhost:2809", clientSC, null);         ObjectGrid og = ogManager.getObjectGrid(ccContext, "accounting");          return og;      }  }

   There are three things different from the non-secured application:

   1. Created a ClientSecurityConfiguration object by passing the configured client.properties file.
   2. Created a UserPasswordCredentialGenerator by using the passed-in user ID and password.
   3. Connected to the catalog server to obtain an ObjectGrid from the ClientClusterContext by passing a ClientSecurityConfiguration object.
5. Issue the application
   

   To run the application, start the catalog server. Issue the -clusterFile and -serverProps command line options to pass in the security properties:

   1. Navigate to the bin directory:

      cd objectgridRoot/bin

   2. Launch the catalog server:
      • 

        startOgServer.sh catalogServer -clusterSecurityFile ../security/security.xml  -serverProps ../security/server.properties -jvmArgs  -Djava.security.auth.login.config="../security/og_jaas.config"

      • 

        startOgServer.bat catalogServer -clusterSecurityFile ../security/security.xml  -serverProps ../security/server.properties -jvmArgs  -Djava.security.auth.login.config="../security/og_jaas.config" 

   Then, launch a secure container server by using the following script:

   1. Navigate to the bin directory again:

      cd objectgridRoot/bin

   2. Launch a secure container server:
      • 

        startOgServer.sh c0 -objectgridFile ../xml/SimpleApp.xml  -deploymentPolicyFile ../xml/SimpleDP.xml  -catalogServiceEndPoints localhost:2809  -serverProps ../security/server.properties  -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"

      • 

        startOgServer.bat c0 -objectgridFile ../xml/SimpleApp.xml  -deploymentPolicyFile ../xml/SimpleDP.xml  -catalogServiceEndPoints localhost:2809  -serverProps ../security/server.properties  -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"

   The server property file is passed by issuing -serverProps.
   After the server is started, start the client by using the following command:

   1. cd objectgridRoot/bin

   2. java -classpath ../lib/objectgrid.jar;../applib/secsample.jar 		com.ibm.websphere.objectgrid.security.sample.guide.SecureSimpleApp 		../security/client.properties manager manager1

      Use a colon (:) for the classpath separator instead of a semicolon (;) as in the previous example.

   The secsample.jar file contains the SimpleApp class.

   The SecureSimpleApp uses three parameters that are provided in the following list:

   1. The ../security/client.properties file is the client security property file.
   2. manager is the user ID.
   3. manager1 is the password.

   After you issue the class, the following output results:

   The customer name for ID 0001 is fName lName.

   You may also use xsadmin to show the mapsizes of the "accounting" grid.

   • Navigate to the directory objectgridRoot/bin.
   • Use the xsadmin command with option -mapSizes as follows.
     • xsadmin.sh -g accounting -m mapSet1 -username manager -password manager1 -mapSizes
     • xsadmin.bat -g accounting -m mapSet1 -username manager -password manager1 -mapSizes

     You see the following output.

     This administrative utility is provided as a sample only and is not to be considered a fully supported component of the WebSphere eXtreme Scale product.

     Connecting to Catalog service at localhost:1099

     *********** Displaying Results for Grid - accounting, MapSet - mapSet1 ***********

     *** Listing Maps for c0 ***

     Map Name: customer Partition #: 0 Map Size: 1 Shard Type: Primary

     Server Total: 1

     Total Domain Count: 1

   Now you can use stopOgServer command to stop the container server or catalog service process. However you need to provide a security configuration file. The sample client property file defines the following two properties to generate a userID/password credential (manager/manager1).

   credentialGeneratorClass=com.ibm.websphere.objectgrid.security.plugins.builtins.UserPasswordCredentialGenerator 

   credentialGeneratorProps=manager manager1

   Stop the container c0 with the following command.

   • stopOgServer.sh c0 -catalogServiceEndPoints localhost:2809 -clientSecurityFile ..\security\client.properties
   • stopOgServer.bat c0 -catalogServiceEndPoints localhost:2809 -clientSecurityFile ..\security\client.properties

   If you do not provide the -clientSecurityFile option, you will see an exception with the following message.

   >> SERVER (id=39132c79, host=9.10.86.47) TRACE START:

   >> org.omg.CORBA.NO_PERMISSION: Server requires credential authentication but there is no security context from the client. This usually happens when the client does not pass a credential the server.

   vmcid: 0x0

   minor code: 0

   completed: No

   You can also shut down the catalog server using the following command. However, if you want to continue trying the next step tutorial, you can let the catalog server stay running.

   • stopOgServer.sh catalogServer -catalogServiceEndPoints localhost:2809 -clientSecurityFile ..\security\client.properties
   • stopOgServer.bat catalogServer -catalogServiceEndPoints localhost:2809 -clientSecurityFile ..\security\client.properties

   If you do shutdown the catalog server, you will see the following output.

   CWOBJ2512I: ObjectGrid server catalogServer stopped

   Now, you have successfully made your system partially secure by enabling authentication. You configured the server to plug in the user registry, configured the client to provide client credentials, and changed the client property file and cluster XML file to enable authentication.

   If you provide an invalidate password, you see an exception stating that the user name or password is not correct.

   For more details about client authentication, see Application client authentication.

1. Java SE security tutorial - Step 1
   This topic describes a simple unsecured sample. Additional security features are added incrementally in the steps of the tutorial to increase the amount of integrated security that is available.
2. Java SE security tutorial - Step 2
   Building on the previous step, the following topic shows how to implement client authentication in a distributed eXtreme Scale environment.
3. Java SE security tutorial - Step 3
   After authenticating a client, as in the previous step, you can give security privileges through eXtreme Scale authorization mechanisms.
4. Java SE security tutorial - Step 4
   The following step explains how you can enable a security layer for communication between your environment's endpoints.

Here I have described how to create client/server keystores which can be used to secure Axsi2 webservices and invoke Axis2 secured webservices. i.e. It can be easily used with any WSO2 Product to experience security scenarios.More detailed explanation on creating client/server keystores using openssl including Certificate Authority(CA) Requests, can be found at http://wso2.org/library/174.

Java keytool stores the keys and certificates in a keystore, protected by a keystore password. Further, it protects private key again with another password. A Java keystore contains private-public key pair and multiple trusted certificate entries. All entries in a keystore are referred by aliases. Both private key and self signed public key is referred by one alias while any other trusted certificates are referred by different individual aliases.

As the first step, let's create a keystore for server. In order to do it, execute following command in a terminal. "server" in the following command corresponds to the private key/self signed public key certificate alias in the keystore while "server.jks" is the name of the creating keystore file.

keytool -genkey -alias server -keyalg RSA -keystore server.jks

when you execute the above command it will first prompt you to specify a password which is corresponded to the keystore password. Then it will prompt several questions. You can give answers that you wish. At the end it will ask for a password again, which will be used to secure the generated private key.

Enter keystore password: 
Re-enter new password:
What is your first and last name?
[Unknown]: Ruchira Wageesha
What is the name of your organizational unit?
[Unknown]: Mashup Server
What is the name of your organization?
[Unknown]: WSO2
What is the name of your City or Locality?
[Unknown]: Ahangama
What is the name of your State or Province?
[Unknown]: Southern
What is the two-letter country code for this unit?
[Unknown]: LK
Is CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK correct?
[no]: yes
Enter key password for
(RETURN if same as keystore password):

Once you successfully completed this, java keytool will create a file named "server.jks". In the same way, you can create a client keystore named "client.jks" with the alias "client" using following command.

keytool -genkey -alias client -keyalg RSA -keystore client.jks

Now, you have two files named client.jks and server.jks. You can view the content of these keystore files using the following command. Replacess "ruchira" with the keystore password you entered while creating the keystore.

keytool -list -v -keystore server.jks -storepass ruchira

This will list something like this.

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: server
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

The next step is, getting server's self signed public key certificate and storing it in client's keystore. And getting and storing client's self signed public key certificate in server's keystore. In order to do that, first we need to export both server and client public key certificates into files. Using the following command, you can export server's public key certificate into server.cert file and client's public key certificate into client.cert file.

keytool -export -file server.cert -keystore server.jks -storepass ruchira -alias server
keytool -export -file client.cert -keystore client.jks -storepass ruchira -alias client

Now you have server.cert and client.cert. You can use following commands to view certificate contents.

keytool -printcert -v -file server.cert
keytool -printcert -v -file client.cert

As the last step, we need to import server.cert into client keystore and client.cert into server keystore. As I mentioned earlier, each entry of a Java Keystore is stored against an alias. So, we need to specify aliases here, which will be used to refer the certificates that we are going to store.

keytool -import -file client.cert -keystore server.jks -storepass ruchira -alias client

Above command will store client's self signed public key certificate(client.cert) in server.jks against the alias "client". So, using "client" alias on server.jks, we can refer client's certificate anytime. Likewise, following command will store server.cert within client.jks against the alias "server".

keytool -import -file server.cert -keystore client.jks -storepass ruchira -alias server

After all, please view the content of both keystore again using following commands.

keytool -list -v -keystore server.jks -storepass ruchira
keytool -list -v -keystore client.jks -storepass ruchira

It will give you something like bellow for server.jks

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: server
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c3562a0
Valid from: Thu Jul 08 11:01:12 IST 2010 until: Wed Oct 06 11:01:12 IST 2010
Certificate fingerprints:
MD5: AB:77:72:F1:0D:09:55:E3:B6:D3:DC:A6:4D:D4:39:36
SHA1: D7:C1:60:5C:7E:34:40:A9:0B:E4:2C:65:6C:E0:79:7C:EE:37:A7:19
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

Alias name: client
Creation date: Jul 8, 2010
Entry type: trustedCertEntry

Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

something like below for client.jks

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: server
Creation date: Jul 8, 2010
Entry type: trustedCertEntry

Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c3562a0
Valid from: Thu Jul 08 11:01:12 IST 2010 until: Wed Oct 06 11:01:12 IST 2010
Certificate fingerprints:
MD5: AB:77:72:F1:0D:09:55:E3:B6:D3:DC:A6:4D:D4:39:36
SHA1: D7:C1:60:5C:7E:34:40:A9:0B:E4:2C:65:6C:E0:79:7C:EE:37:A7:19
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

Alias name: client
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

If everything went well, you might have successfully created server.jks and client.jks which can be used to secure Axis2 Services and access those secured services.