This topic describes how to secure the exchange of data among components in the Common Auditing Service audit server and Web Service clients. If you are using the C client to generate events in a WebSphere Application Server single server environment, see "Securing C client events."
Securing C client events
Enabling security for event logging from the Common Auditing Service C client involves configuring the server and the client. Server configuration involves: v Enabling WebSphere Application Server global security.
v Using the WebSphere Application Server Secure Sockets Layer (SSL) functionality.
v Mapping Common Auditing Service Web service roles to users or groups.
The C client configuration involves specifying the keyring (.kdb) and stash (.sth) files for SSL and user name and password for client authentication.
Configuring the server
Configuring the server to use the client involves setting up: v WebSphere Application Server security
v Secure Sockets Layer (SSL)
v Security roles for users and groups
WebSphere Application Server security
The following steps are required to set up WebSphere Application Server security:
Procedure
1. Log on to the WebSphere Application Server administrative console.
2. Configure the user registry as described in one of the following procedures for the different user registries:
v Local operating system registry:See “Configuring the operating system
registry” on page 158.
v LDAP registry:See “Configuring the LDAP registry” on page 158.
v Custom registry: See “Configuring a custom registry” on page 160.
v Federated registry: See “Configuring a federated registry” on page 160.
3. Enable the administrative and application security option for the configured user registry:
a. Click Security > Global security to display the "Global security" panel. b. Select Enable administrative security.
c. Select Enable application security.
d. In User account repository > Available realm definitions, select the configured user registry (for example, Standalone LDAP registry). e. In User account repository, click Set as current. This selection validates
f. Click Apply and then save the changes. If you are in a WebSphere Application Server Network Deployment environment, be sure to select
Synchronize changes with Nodesbefore you save the changes.
4. Manually add the security policy for the DB2 JDBC driver. See Configuring security policy for the JDBC provider.
5. Enable the Java 2 security option:
a. Click Security > Global security > Use Java 2 security to restrict
application access to local resources.
b. Select Warn if applications are granted custom permissions. c. Select Restrict access to resource authentication data. 6. Click Apply and save the changes.
Configuring the operating system registry:
Configure the local operating system registry settings.
About this task
This task covers the steps to configure a local operating system registry. However, use an LDAP registry (or a federated repository that includes an LDAP registry) for the following scenarios:
v You want to maintain consistency of the registry between nodes in a clustered environment.
v The Network Deployment cell (all of the nodes) is not on a single server.
v WebSphere Application Server is running on AIX, Linux, or Solaris as a non-root user.
See “Configuring the LDAP registry.”
Procedure
1. Log on to the WebSphere Application Server administrative console. 2. Click Security > Global security to display the "Global security" panel. 3. In User account repository > Available realm definitions, select Local
operating systemfrom the drop-down list.
4. Click Configure.
5. Specify the Primary administrative user name property, which is a user with administrative privileges who is defined in the local operating system. 6. Select one of the following options:
v Click Automatically generated server identity.
v Click Server identity that is stored in the repository and specify the following properties:
– Server user ID (for example, root). This value must be a valid user ID in the local operating system registry.
– Server user password (for example, abc26xyz). 7. Click OK and then save the changes.
Use Lightweight Directory Access Protocol (LDAP) user registries when users and groups are in an external LDAP directory. In clustered environments, LDAP registries are used to maintain consistency of the registry between nodes in the cluster.
About this task
Use an LDAP registry (or a federated repository that includes an LDAP registry) for the following scenarios:
v You want to maintain consistency of the registry between nodes in a clustered environment.
v The Network Deployment cell (all of the nodes) is not on a single server.
v WebSphere Application Server is running on AIX, Linux, or Solaris as a non-root user.
Procedure
1. Log on to the WebSphere Application Server administrative console. 2. Click Security > Global security to display the "Global security" panel. 3. In User account repository > Available realm definitions, select Standalone
LDAP registryfrom the drop-down list.
4. Click Configure.
5. Specify the Primary administrative user name property, which is a name of a user in your LDAP registry who has administrative privileges.
6. In the LDAP area, specify the following properties:
v Type of LDAP server: For example, IBM Tivoli Directory Server.
v Host: For example: server1.example.ibm.com. v Port: For example, 389.
v Base distinguished name: For example, ou=tivoli,o=ibm,c=us.
v Search timeout: For example, 120.
v Reuse connection: Enabled by default. This property prevents the LDAP
connection from reestablishing on each LDAP access.
v Ignore case for authorization: Enable this property if your LDAP server
requires it.
7. In the Security area, specify the following properties:
v In the Server user identity area, choose one of the following options: – Select Automatically generated server identity
– Select Server identity that is stored in the repository and specify the following properties:
- Server user ID (for example, root), which is the operating system user ID that the application server is using for security purposes.
- Server user password (for example, abc26xyz).
v Bind distinguished name (for example, cn=root,ou=tivoli,o=ibm,c=us)
v Bind password(for example, abc26xyz)
v Select SSL enabled to enable SSL communication between the LDAP server and WebSphere Application Server. Click Centrally managed to defer the selection of the SSL configuration to the server-wide endpoint management scheme. Otherwise, click Use specific SSL alias and select a configuration scheme from the drop-down list.
8. Click OK and save the changes. If you are in a WebSphere Application Server Network Deployment environment, select Synchronize changes with Nodes before you save the changes.
9. Select Test connection to check the validity of the specified information. Otherwise, the validity of the information is not confirmed until this registry is selected as the current repository.
What to do next
To enable security in a WebSphere Application Server Network Deployment environment by using an LDAP user registry, you must configure LTPA as the active authentication protocol to authenticate the users. See “Configuring the LTPA authentication mechanism” on page 162 for instructions.
Configuring a custom registry:
A custom registry is any registry that implements the
com.ibm.websphere.security.UserRegistryinterface. From the WebSphere Application Server administrative console, configure the custom registry settings.
Procedure
1. Log on to the WebSphere Application Server administrative console. 2. Click Security > Global security to display the "Global security" panel. 3. In User account repository > Available realm definitions, select Standalone
custom registry from the drop-down list.
4. Click Configure.
5. Specify the Primary administrative user name property, which is a name of a user in your custom registry who has administrative privileges.
6. Select one of the following options:
v Click Automatically generated server identity.
v Click Server identity that is stored in the repository and specify the following properties:
– Server user ID (for example, root), which is the operating system user ID that the application server is using for security purposes.
– Server user password (for example, abc26xyz).
7. Specify the Custom registry class name property (for example, com.ibm.websphere.security)
8. Enable the Ignore case for authorization property if your custom class requires it.
9. Click OK and save your changes. If you are in a WebSphere Application Server Network Deployment environment, select Synchronize changes with Nodes before you save the changes.
Configuring a federated registry:
A federated registry allows consolidation of multiple repositories into a single virtual registry.
About this task
From the WebSphere Application Server administrative console, configure the federated registry settings:
Procedure
1. Log on to the WebSphere Application Server administrative console. 2. Click Security > Global security to display the "Global security" panel. 3. In User account repository > Available realm definitions, select Federated
repositoriesfrom the drop-down list.
4. Click Configure.
5. Specify the Realm name.
6. Specify the Primary administrative user name property, which is the name of a user in one of the federated registries who has administrative privileges. 7. Select one of the following options:
v Click Automatically generated server identity.
v Click Server identity that is stored in the repository and specify the following properties:
– Server user ID (for example, root). This value must be a valid user ID in the local operating system registry.
– Server user password (for example, abc26xyz).
8. Optional: Enable the Ignore case for authorization property if case sensitivity is not important.
9. Optional: Enable the Allow operations if some of the repositories are down property if you want operations to continue when a repository is down. 10. Use the Repositories in the realm table to manage the repositories that you
want federated. Optionally, you can add the built-in file repository and any external LDAP registries.
11. Click OK and save your changes. If you are in a WebSphere Application Server Network Deployment environment, select Synchronize changes with
Nodesbefore you save the changes.
Configuring the security policy for the JDBC provider:
A JDBC provider JAR file and directory path are configured to access the DB2 Audit Database (XML data store). If Java 2 security is enabled, this JAR file must be granted access permissions before it is configured into the WebSphere
Application Server by using the configuration console.
About this task
To grant access permissions to the JAR file, add the appropriate grant policy to the app.policyfile that is in the target node. For a cluster configuration, the target node is the Deployment Manager node; for a stand-alone server, the target node is the server parent node.
Procedure
1. Start the wsadmin tool of the target profile for which you want to configure a Common Audit Service server instance
2. Extract the policy file to a temporary location with the following command: wsadmin>set obj [$AdminConfig extract
cells/cell_name/node/node_name/app.policy
temp_file_path/app.policy]
If you are using Deployment Manager, set the node_name value for a CellManager node.
Use either a single forward slash (/) or a double back slash (\\) while you specify the path on Windows, do not use a single back slash (\) to specify the path.
3. In a separate shell, run the Policy Tool to edit the extracted app.policy file. See “Editing the app.policy file using the Policy Tool” for detailed instructions on using the Policy Tool. The following list summarizes the changes that you must make.
a. Create a policy with codeBase "file:JDBC_driver_path/db2jcc.jar". b. Add the permission "AllPermission".
c. Save the policy file.
4. Check the policy file back into the WebSphere Application Server node with the following command:
wsadmin>$AdminConfig checkin cells/cell_name/node/node_name/app.policy
temp_file_path/app.policy &obj
Editing the app.policy file using the Policy Tool:
The Policy Tool is a utility to enable editing of Java policy files, such as app.policy. Update the policy for the JDBC provider.
Procedure
1. Start the Policy Tool with the following command:
v On AIX, Linux, and Solaris platforms: was_install_root/java/jre/bin/ policytool
v On Windows platforms: was_install_root\java\jre\bin\policytool.exe The tool looks for the java.policy file in the home directory. If it does not exist, an error message is displayed.
2. To dismiss the error, click OK. 3. Click File-> Open.
4. Navigate the directory tree in the Open window to the temporary file
temp_file/app.policy. Select the file and click Open. The existing code base entries are listed in the window.
5. Create a code base entry by clicking Add Policy Entry.
6. In the Policy Entry window, in the code base column, add the string file:JDBC_driver_path/db2jcc.jar, where JDBC_driver_path represents the path to your JDBC driver. Use a forward slash (/) to specify JDBC_driver_path. 7. Click Add Permission to add the permission for the JDBC driver.
8. In the permissions window, select the AllPermission entry in the drop-down list.
9. Click OK.
10. In the Policy Entry window, the string permission
java.security.AllPermission is displayed beneath the Permission buttons. Click Done.
11. Click File-> Save to save the updated file. 12. Click File-> Exit to exit the tool.
Configuring the LTPA authentication mechanism:
From the WebSphere Application Server administrative console, configure Lightweight Third-Party Authentication (LTPA) token authentication.
Procedure
1. Click Security > Global security > LTPA.
2. In the Key Generation area, Key set group option, complete the following steps:
a. Select the NodeLTPAKeySetGroup key set group. b. Click Generate keys.
3. Under Authentication expiration, specify the following properties: v Authentication cache timeout
v Timeout value for forwarded credentials between servers (for example, 120) 4. Click OK and save the changes. If you are in a WebSphere Application Server Network Deployment environment, select Synchronize changes with Nodes before you save the changes.
5. Click Global security.
6. Click OK and save the changes. If you are in a WebSphere Application Server Network Deployment environment, be sure to select Synchronize changes with
Nodesbefore you save the changes.
Restarting the cluster:
From the WebSphere Application Server administrative console, restart the cluster to enable the global security method.
Procedure
1. Expand Servers.
2. Click Clusters and select the target cluster. 3. Click Stop.
4. Stop and restart the deployment manager system with the WebSphere Application Server security enabled method.
5. Stop and restart the agent on the managed nodes with the WebSphere Application Server security enabled method.
6. Expand Servers.
7. Click Clusters and select the target cluster. 8. Click Start.
What to do next
From this point on, use the WebSphere Application Server security enabled method for stopping and starting the Deployment Manager and managed nodes.
Configuring SSL
This topic describes how to configure SSL for securing Web service client communications.
Following are three ways you can configure SSL: v Configure WebSphere Application Server for SSL.
v Configure SSL communication between the IBM HTTP Server plug-in and the WebSphere Application Server.
v Configure the IBM HTTP Server for SSL (required in a clustered environment).
Configure WebSphere Application Server Secure for Secure Sockets Layer (SSL) authentication.
Procedure
1. Create an SSL configuration entry:
a. Click Security > SSL certificate and key management. b. Click SSL Configuration from the Related Items list.
c. Click New to create an SSL configuration specifically for Common Auditing Service.
d. Specify Name as CARSSSLConfiguration.
e. Specify Trust store name (for example, CellDefaultKeyStore). f. Specify Keystore name (for example, CellDefaultKeyStore). g. Click Get certificate aliases.
h. Specify Default server certificate alias (for example, as default). i. Specify Default client certificate alias (for example, as default). j. Click OK and save the changes. If you are in a WebSphere Application
Server Network Deployment environment, select Synchronize changes with
Nodesbefore you save the changes.
2. Configure SSL between the WebSphere Application Server and the Web service client. To do this configuration, assign an SSL configuration to a WebSphere Application Server configuration scope that enables the port for encryption and decryption of inbound data.
a. Click Security > SSL certificate and key management > Manage endpoint
security configurations.
b. In the inbound local topology tree, click the cluster or server name into which Common Auditing Service is being deployed.
c. Under Specific SSL configuration for this endpoint, enable Override
inherited values.
d. Select CARSSSLConfiguration from within the SSL configuration field. e. Click Update certificate alias list.
f. Specify the certificate alias in the keystore from the drop-down list (for example, default).
g. Click OK and save the changes.
h. Click Security > SSL certificate and key management.
i. Select to dynamically update the run time when SSL configuration changes occur.
j. Click Apply and save the changes. If you are in a WebSphere Application Server Network Deployment environment, select Synchronize changes with
Nodesbefore you save the changes.
Configuring the Web server plug-in for SSL:
This topic describes how to set SSL security for communication between the Web server and a WebSphere Application Server Web server plug-in.
About this task
The Web server plug-in can be enabled to securely communicate with the corresponding Web server, which might be critical because the Web server is usually remote to at least some of the nodes in the cluster. See “Configuring a Web
server that is installed on a system outside the cluster” on page 45 for information about configuring the Web server plug-in.
Take these steps to implement security by using the SSL protocol for communication between the Web server and the Web server plug-in that is configured in a WebSphere Application Server cluster.
Procedure
1. From the WebSphere Application Server Administrative Console, click
Servers->Web servers. 2. Select the Web server name. 3. Click Plug-in properties.
4. Under Repository copy of Web server plug-in files, specify the keystore file name (or accept the default name) in the following field:
Plug-in keystore file name
Stores the cryptographic keys for the plug-in. The default value is Plugin-key.kdb.
5. Under the Web server copy of Web server plug-in files, specify the keystore filepath in the following field:
Plug-in keystore directory and file name
The filepath is WAS_HOME/Plugins/config/webserver_name/Plugin- key.kdb.
6. Click Manage keys and certificates to access configuration options for your keys and certificates. By default, you can change the password that you use to protect the keystore.
7. Click Apply to save the password changes.
8. Under Additional Properties, you can also select the following options:
Signer certificates
Use this option to add new certificates, delete certificates, extract certificates, and to retrieve certificates from a port.
Personal certificates
Use this option to create a new self-signed certificate, delete a certificate, or to import and export a personal certificate.
Personal certificate requests
Use this option to manage personal certificate requests.
Custom properties
Use this option to define custom properties for the keystore.
9. Click Personal certificates and confirm that at least one personal certificate is in the keystore.
10. Click Servers-> Web servers-> webserver_name-> Plug-in properties->
CMSKeyStore->Copy to Web server key store directoryto copy the keystore
and to stash the files to a managed Web server.
Configuring the IBM HTTP Server for SSL:
This topic describes how to configure the IBM HTTP Server for SSL. SSL is required in a WebSphere Application Server clustered environment.
Before you begin
The Common Auditing Service web service client can start the Common Auditing Service either directly by talking to the WebSphere Application Server embedded HTTP server, or indirectly by first going through a web server. The web server can be the IBM HTTP Server or another third-party web server. The web server must be enabled for SSL for secure communication with the client. SEe the appropriate web server documentation for details on how to enable SSL.
Procedure
1. Use the IBM HTTP Server IKEYMAN utility to create a CMS key database file and insert the personal certificate of the server.
For example, to create a CMS key database file, open the CARSServerKey.jks file in iKeyman and then save it as a CMS file. Copy the CARSServerKey.kdb