WebSphere Security.
Configuring security with scripting
You can configure security with scripting and the wsadmin tool.
Before you begin
About this task
If you enable security for a WebSphere Application Server cell, supply authentication information to communicate with servers. The sas.client.props and the soap.client.props files are located in the following properties directory for each WebSphere Application Server profile:
Procedure
- The nature of the properties file updates required for running in secure mode depend on whether you connect with a Remote Method Invocation (RMI) connector, or a SOAP connector:
- If you use a Remote Method Invocation (RMI) connector, set the following properties in thesas.client.props file with the appropriate values:
o com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=
Also, set the following property:
com.ibm.CORBA.loginSource=properties
The default value for this property is prompt in the sas.client.props file. If you leave the default value, a dialog box appears with a password prompt. If the script is running unattended, it appears to hang.
- If you use a SOAP connector, set the following properties in the soap.client.props file with the appropriate values:
o com.ibm.SOAP.securityEnabled=true
o com.ibm.SOAP.loginUserid=
com.ibm.SOAP.loginPassword=
Optionally, set the following property:
com.ibm.SOAP.loginSource=none
The default value for this property is prompt in the soap.client.props file. If you leave the default value, a dialog box appears with a password prompt. If the script is running unattended, it appears to hang.
- Specify user and password information. Choose one of the following methods:
- Specify user name and password on a command line, using the -user and -passwordcommands. For example:
wsadmin -conntype RMI -port 2809 -user u1 -password secret1
- Specify user name and password in the sas.client.props file for a RMI connector or thesoap.client.props file for a SOAP connector.
If you specify user and password information on a command line and in the sas.client.props file or thesoap.client.props file, the command line information overrides the information in the props file.
Note: The use of -password option may result in security exposure as the password information becomes visible to the system status program such as ps command which can be invoked by other user to display all the running processes. Do not use this option if security exposure is a concern. Instead, specify user and password information in the soap.client.props file for SOAP connector or sas.client.props file for RMI connector. The soap.client.props and sas.client.props files are located in the properties directory of your WebSphere Application Server profile
To run any command without exposing the password in the command line, use the below format command for any operation through shell.
WAS-TEST:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin #./stopManager.sh -conntype SOAP
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/dmgr/stopServer.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU3100I: Reading configuration for server: dmgr
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server dmgr stop completed.
Example: Enabling and disabling Java 2 security using wsadmin
An example of enabling and disabling Java 2 security follows:
- Identify the security configuration object and assign it to the security variable:
Using Jacl:
set security [$AdminConfig list Security]
An example of this output follows:
(cells/mycell:security.xml#Security_1)
![[Version 5.1 and later]](file:///C:/DOCUME~1/delango/LOCALS~1/Temp/msohtml1/12/clip_image001.gif)
Using Jython:security = AdminConfig.list('Security')
print security
- Modify the enforceJava2Security attribute.
To enable Java 2 security:
Using Jacl:
$AdminConfig modify $security {{enforceJava2Security true}}
Using Jython: AdminConfig.modify(security, [['enforceJava2Security', 'true']])
To disable Java 2 security:
Using Jacl:
$AdminConfig modify $security {{enforceJava2Security false}}
Using Jython: AdminConfig.modify(security, [['enforceJava2Security', 'false']])
- Save the changes with the following command:
Using Jacl:
$AdminConfig save
Using Jython: AdminConfig.save()
IF the security has to be disabled through wsadmin:
Specifies whether to enable or disable Java 2 Security permission checking. By default, Java 2 security is disabled. However, if you enabled global security, this automatically enables Java 2 security. You can choose to disable Java 2 security, even when global security is enabled.
When Java 2 Security is enabled and if an application requires more Java 2 security permissions then are granted in the default policy, then the application might fail to run properly until the required permissions are granted in either the app.policy file or the was.policy file of the application. AccessControl exceptions are generated by applications that do not have all the required permissions. Consult the InfoCenter and review the Java 2 Security and Dynamic Policy sections if you are unfamiliar with Java 2 security.
If your server does not restart after you enable global security, you can disable security. Go to your${was_install_root}\bin directory.
Excecute the command wsadmin -conntype NONE.
At the wsadmin> prompt, enter securityoff.
Type exit to get back to a command prompt.
Now you should be able to start the server again, with security disabled. This enables you to check what might not be set correctly through the administrative console.
Data type | Boolean |
Default | Disabled |
Range | Enabled or Disabled |
