Enable and disabling global security
You can decide whether to enable IBM WAS security. You must enable security for all other security settings to function.
- Enable global security in the WAS. It is important to click Security > Global Security and set the Enabled flag to on so that security is enabled upon a server restart.
- Before cycling the server, log off the administrative console. You can log off by clicking Logout at the top menu bar.
- Stop the server by going to the command line in the WAS /bin directory and issue a stopServer <server_name> command.
- Restart the server in secure mode by issuing the command startServer <server_name>. Once the server is secure, you cannot stop the server again without specifying an administrative user name and password. To stop the server once security is enabled, issue the command, stopServer <server_name> -username <user_id> -password <password>. Alternatively, you can edit the soap.client.props file in the $WAS_HOME/properties directory and edit the com.ibm.SOAP.loginUserid or com.ibm.SOAP.loginPassword properties to contain these administrative IDs.
If you have any problems cycling the server, review the output logs in the $WAS_HOME/logs/server_name directory. Check the Troubleshooting Security article for any common problems.
Disable global security
- Click Security > Global Security and set the Enabled flag to off so that security gets disabled upon a server restart.
- Before cycling the server, log off of the administrative console. You can log out by clicking Log off at the top menu bar.
- Stop the server by going to the command line, accessing the WebSphere Application Server /bin directory, and issuing the following command on one continuous line...stopServer server_name -username <administrative_user_name> -password -<administrative_password>STOP <appserver_proc_name>,JOBNAME=<server_short_name>, ENV=<cell_short_name>.<node_short_name>.<server_short_name>
- Issue the following command to restart the server in secure mode...
- If you have any problems cycling the server, review the output logs in the $WAS_HOME/logs/server_name directory.
This scenario is specifically for a stand-alone setup where you have a single appserver and likely utilize your Local OS registry for your repository of users. The authentication mechanism is probably SWAM. The appserver cannot communicate securely to other appservers as the SWAM authentication mechanism does not contain a forwardable token to send to downstream servers.
After cycling the server in secure mode, run a couple of simple tests to verify that most facets of security are working properly.
- Test basic authentication with snoop by accessing the following URL: http://hostname.domain:9080/snoop. A login panel appears. Type in any valid user ID and password in your configured user registry. If the login panel fails to appear, there is a problem.
- Test the Java client with dumpNameSpace by executing the $WAS_HOME\bin\dumpNameSpace.bat file. A login panel appears. Type in any valid user ID and password in your configured user registry. If the login panel fails to appear, there is a problem.
- Test form login by bringing up the administrative console: http://hostname.domain:9090/admin. A form-based login page appears. Type in the administrative user ID and password that was used for configuring your user registry when configuring security. When the Authentication Mechanism is set as LTPA, provide a fully qualified host name (for example, myhost.companyname.com:9090, rather than just myhost:9090). If the login panel fails to appear, there is a problem.
If you encountered a problem with any of these tests, check the WebSphere Application Server /logs/server_name/SystemOut.log file for hints about the problems that occurred. Also refer to Troubleshooting Security for solutions.
See AlsoJava 2 security policy files
Configuring user registries
Configuring Lightweight Third Party Authentication
Global security settings
Java 2 security