Log in to the WebSphere Console. Before global security is enabled, the Console will only have one field in which to enter an ID. This ID can actually be anything since we have not linked our WebSphere environment to any user registry. (The use of the term User ID may be misleading. At this stage, WebSphere uses that field as a temporary tag to label an area in which to save any changes that may be made during the session until they are either committed or discarded.) Access the Deployment Manager Console using a browser, enter a value for User ID and click the Log in button. Prior to enabling global security, part of the Console log in page will look similar to the portion shown in the following screenshot.

We first need to open the Global security page. After logging in, expand the Security leaf on the left pane of the console, and then click on the Global security link as shown in the following figure. The global security page will be displayed on the right hand pane.

Next, let's open the SSO page. Expand the Web and SIP security leaf under the Authentication section on the right section of the Global security page (figure shown previously). Click on the Single sign-on (SSO) link. A portion of the SSO page is shown in the next screenshot.

Under the General Properties section, enter the SSO domain name in the corresponding field, as shown in the previous screenshot. Use the default selections for the rest of the parameters.

Keeping as a reference the previous screenshot under the section Onto the SSO page, saving the changes is in order. Click the OK button. You will be sent back to the Global security page. A Messages box is displayed at the top of the page giving you the opportunity to save your changes. The message is shown in the following screenshot:

Save your work as you normally would have for any other configuration modifications of your environment in the past, ensuring that the changes are propagated to all your existing nodes in this cell.

It is important to ensure that any of the changes made while enabling global security are synchronized with all of the nodes in the cell as they are saved by the deployment manager. Failing to do this may prevent the nodes from getting the new configuration and they may be unable to communicate with the deployment manager.

Open the WebSphere Console Global security page. If you have closed your browser, you need to open the Deployment Manager Console and log in as you did in the first stage. (If needed, refer to the section "Starting at the Console"). Next, expand the Security leaf and click on the Global security link, as you did in the second step of the first phase. During this stage, we will pay attention to the User account repository section (shown in the following figure).

We continue by selecting the user registry type. The first thing we need to tell WebSphere is the type of user registry to which we wish WebSphere to connect. The default type is the local OS authentication mechanism. The supported registry types are shown in the following screenshot:

In the next sections, we look very briefly at each of the options supported by WAS ND7.

In most scenarios, it is likely that you will be using a type of standalone LDAP server. Select the Standalone LDAP registry option from the Available realm definitions pull-down menu. Once the standalone LDAP registry type is selected, click the Set as current button. The value of the Current realm definition field updates to the selected value as shown in the following screenshot:

Simultaneously, as a result of the previous action, a warning message is displayed at the top of the Standalone LDAP registry page, as shown in the next screenshot. The deployment manager is just reminding us that the configuration we are about to make will not become active until we turn on global security.

Under the General Properties section, enter the value for the WebSphere administrative ID in the Primary administrative user name field. For the purposes of this chapter, we are using the fictitious value wasadm, as shown in the following screenshot. For additional information on this value refer to the LDAP and security table section.

Next, we need to select the type of LDAP server. The default type is the IBM Tivoli Directory Server. The supported LDAP server types are shown in the next screenshot. Obviously, your choice will depend on the type of LDAP server used by your company.

Using the values you gathered in the first section of this chapter, Information needed: planning for security, enter the LDAP server host name value in the Host field. The fictitious value jsdsdev01.yourcompany.com is being used in our example. Next, enter the LDAP server TCP port value in the Port field. We are using the standard TCP port 389. The following screenshot shows how these values are displayed in the Standalone LDAP registry page.

Once the primary parameters that identify the LDAP server have been specified, we need to designate the parameters to be used by WebSphere to connect to the LDAP registry. In the field designated as Base distinguished name (DN), enter the value for LDAP Base Distinguished Name identified in the Information needed: planning for security section. We will be using the value o=yourcompany.com. Next, enter the Bind Identity value in the Bind distinguished name (DN) field. The full value shown in the following screenshot is uid=wasbind,ou=service,o=yourcompany.com. Finally, enter the corresponding password for the bind ID in the field that is designated as Bind password. These values are shown as displayed in the Standalone LDAP registry page in the following screenshot:

In general, the default value of the remaining parameters for the LDAP server works just fine in most situations. Normally, there will be no need to modify the default values shown in the following screenshot. However, if for instance, the LDAP server to be used with this particular WebSphere environment only accepts SSL connections, that fact would have to be reflected by checking the SSL enabled check box under the SSL settings section of the Standalone LDAP registry page. In a similar way, if your particular LDAP server has other requirements that are not covered by the default selections shown in the following figure, adjust the corresponding parameter accordingly.

At this point, all that is left to complete the configuration of the standalone LDAP registry is to commit the new configuration values just entered. Click the Apply button, located at the bottom of the page. In the resulting page, a Messages section appears at the top of the page. Use the appropriate link to save your work, always insuring that the changes are synchronized with any existing node agent.

Before concluding this portion of the configuration, it is best practice to confirm that the deployment manager can connect and log in the LDAP server. Identify and click on the Test connection button located near the top of the page, just above the General Properties section. If your configuration is correct, a Messages section is displayed at the top of the page, similar to the one shown in the next screenshot. If an error occurred, a corresponding message will be displayed. Correct the error and test the connection again.

Open the WebSphere Console Global security page. If you have closed your browser, you need to open the Deployment Manager Console and log in as you did in the previous two stages. (If needed, refer to the first step of the first stage.) Next, expand the Security leaf and click on the Global security link, as you did in the second step of the first stage. This time we are going to focus on the Administrative security section, as shown in the following screenshot:

Under the Administrative security section, check the Enable administrative security box. You will notice that the box labeled Use Java 2 security to restrict application access to local resources is checked automatically. Normally, you do not want this box to be checked, so remove the check from Java 2 security. The main reason for choice is that it is not uncommon for enterprise applications to require Java 2 security access that surpasses the default security policies. When this fact is present, enterprise applications are likely to either fail or function differently as designed. Therefore, modifications to the application's app.policy or was.policy, as appropriate, would be required. Additional information about these files can be found at http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rsec_rpolicydir.html. An alternative to employing Java 2 security is to use an external access control policy manager, for example, IBM Tivoli Access Manager or the popular CA SiteMinder Policy Server. Moreover, Chapter 3 describes alternative locations in the administrative console where the Java 2 security can be enabled for a limited number of applications that require it.

Your selections should be as those shown in the following screenshot:

On the same Global security page, scroll down. Click the Apply button, located at the bottom. It is likely that WebSphere may display a long Messages section as the one shown in the next screenshot:

Summarizing these warning messages, they tell us what to do if one or more node agents belonging to this cell are not active in order to propagate our configuration changes to each node agent configuration repository.

After reading the warning messages, click on the Save link to commit your changes to the WebSphere configuration repository. However, if you have not enabled automatic synchronization with the nodes after each save, then click on the Review link instead so you have the chance to indicate that you wish these changes to be propagated to the nodes in the cell.

Once you have saved your changes, you need to allow WebSphere to make those changes active. This is accomplished by restarting the deployment manager. Although not necessary, it is always good practice to log off the console. If there were pending tasks to be saved, the deployment manager would display a message to either save or discard any pending changes before allowing you to log off.

When describing procedures that need to take place at the OS level, in this book it will be assumed that we are working on a Unix or Unix-like environment. If you are working on a different type of OS, it is likely that you are already familiar with the various commands used and can perform the equivalent operations in your particular OS.

Log in to the command line interface of your OS on the server where the deployment manager process is executing. Switch to the user ID used to stop and start the deployment manager process as you normally do. Use the following command:

 <Dmgr_Profile_Path>/bin/stopManager.sh

(Use stopManager.bat in Windows; or the Windows service for WAS). Now you can start the deployment manager. Use the following command:

 <Dmgr_Profile_Path>/bin/startManager.sh

(In Windows, use startManager.bat or the Windows services interface). Ensure that the output does not display any errors.

Using your browser, connect to the WebSphere Console using the same URL you have used before. WebSphere will attempt to redirect you to its secure administrative port. However, your browser will show you a warning message stating the SSL certificate presented by the site is invalid. The deployment manager is presenting its self-signed certificate and the warning message means that your browser does not have a root CA certificate to validate it. This is fine, since it was the configuration we just did that created the SSL certificate. Click on the OK button. Depending on the browser being used you will be presented with the option to cancel or continue. Firefox presents an Or you can add an exception link. IE presents a Continue to this website (not recommended) link. Accept the SSL certificate.

The Integrated Solutions Console opens. One can tell that global security is on by observing that the log in page now has two fields. One field is for the User ID and the other is for the Password. Enter the appropriate credentials (WebSphere administrative ID and password) and click on the Log in button.

Congratulations! You have successfully enabled global security.