How to enable Websphere security | WAS 8

1. To turn on global security, log in to the Admin console and navigate to the Security section of the left-hand-side navigation panel and click Global security:

You will now be taken to the main Global security configuration page as shown in the following screenshot:

 

WebSphere provides a wizard to set up basic security using an internal repository. What we are going to do is run the wizard to secure our Admin console.

2. Click the Security Configuration Wizard button, as shown in the previous screenshot. You will be presented with an option to decide on the extent of your security protection. Leave the screen options set to their default and click Next to move on to the next page, where you will select which type of repository you wish to use.

—> The Use Java 2 security to restrict application access to local resources option, as seen in the Security Configuration Wizard, is used when you do not trust the application’s code. Since, in most cases, you trust the code you are installing in your EAR/WAR files, you do not need to turn this option on.

3. On the Select user repository page, you have four types of repository to choose from, as described previously.

The default repository is built into WebSphere and is based on the platform you are running on.

The simplest way to provide administrative security is to use a file-based standalone custom registry. In our first example, we are going to start by selecting Standalone custom registry during our use of the Global security wizard, as shown in the following screenshot:

 

4. Select Standalone custom registry in the Select user repository screen and click Next.

Before we continue with the wizard we need to set up two property files—one for users and one for groups. These properties files will contain authorized users and groups. Our custom registry will use these two files.

5. We need to create a folder within the WebSphere filesystem called <was_root>/fileRegistry. In this folder, we will create a file called user.props, with the following contents:

# Format:
# name:passwd:uid:gids:display name
# where name = userId/userName of the user
# passwd = password of the user
# uid = uniqueId of the user
# gid = groupIds of the groups that the user belongs to
# display name = a (optional) display name for the user.
wasadmin:wasadmin:101:101:WebSphere Administrator

6. We will then create a second file named group.props; the contents of the file will be as follows:

# Format:
# name:gid:users:display name
# where name = groupId of the group
# gid = uniqueId of the group
# users = list of all the userIds that the group contains
# display name = a (optional) display name for the group.
admins:101:wasadmin:Administrative group

–> You need to ensure that any new files you create are assigned appropriate rights using chmod and chown on Linux to ensure WebSphere processes can read the file. This is not a requirement in Windows as files are accessible by default.

7. In the Configure standalone custom registry page, type wasadmin in the Primary administrative user name and add two properties. The usersFile property will point to the user.props file and the groupsFile property will point to the location of the group.props file, as seen in the following screenshot:

Custom registry class name is already filled in with a Java class that exists in the internals of WebSphere and which contains the code for WebSphere to use the user.props and group.props files. We will not go into detail as to how this class is internally coded; it is beyond the scope of this book as it involves discussing Java programming.

 

8. Click Next to view the summary, and then click Finish to complete your file-based repository, while remembering to Save your configuration when prompted to do so.

9. For the security configuration change to take effect, you will now need to restart WAS. When you next try to log in to the Administrative console, you will be prompted for a username and password. Now that you have enabled global security, you will also notice that your application server will have issues while starting and stopping via the command line; this is because, once Global security is enabled, a username and password is required to stop an application server.

• For Linux:
<was_profile_root>/bin/stopServer.sh server01
• For Windows:
<was_profile_root>\bin\stopServer.bat server01

You will now be presented with a pop-up dialog that requires you to enter a username and password before you can stop the server. An example of what the dialog looks like is shown in the following screeshot:

It can be very annoying having to continuously type in a username and password every time you bounce your server. To stop this, we can alter a file called soap.client.props. The soap.client.props file is located in the <was_profile_root>/properties folder, as shown in the following screenshot:

 

10. Edit the file using the vi command (if using Linux, or your preferred text editor if using Windows) and change the com.ibm.SOAP.securityEnabled setting’s value from false to true. Change the com.ibm.SOAP.loginUserid setting’s value to com.ibm.SOAP.loginUserid=wasadmin and the com.ibm.SOAP.loginPassword setting value to wasadmin.

 

The changes just made can be seen in the following code:

com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.authenticationTarget=BasicAuth
com.ibm.SOAP.loginUserid=wasadmin
com.ibm.SOAP.loginPassword=wasadmin

11. Save the soap.client.props file. Now when you stop and start WAS, you will no longer be prompted for a username and password.

Linux users may see the following error:

ADMU0116I: Tool information is being logged in file /apps/was8/profiles/appsrv01/logs/server01/stopServer.log
ADMU0128I: Starting tool with the appsrv01 profile
ADMU3100I: Reading configuration for server: server01
X connection to localhost: 10.0 broken (explicit kill or server shutdown).

If you do get an X connection error while trying to stop a server, it means that a login pop-up dialog cannot be displayed for the user to authenticate with, as X Windows is not running. One solution could be to simply run XMing.

12. Once global security is enabled, when you try to log in to the standard login URL http://<host_name>:9060/ibm/console, you will be presented with a screen informing you that you are being redirected to a secure site. A warning that you have received a Secure Sockets Layer (SSL) certificate from an unknown Certificate Authority (CA) will be shown in the browser.

If you have problems getting to the port 9060, then it might be because the console wants to redirect to port 9043 (the secure HTTP port for the Admin console), now that we have global security enabled. You might need to change your firewall configuration or temporarily turn off your firewall while you are trying the exercises.You may need to alter both your workstation and server firewall settings.

13. If you are using Internet Explorer, click Continue to this website (not recommended); if you are using Firefox, click I Understand the Risks and then add and confirm a security exception.

Browser versions change and each vendor might show different SSL certificate warnings, worded in different ways, with slightly different recommendations, to solve the problem. Be aware, all they are trying to do is alert you to the fact that the SSL certificates come from an un-trusted certificate authority and you have the choice to continue or not.

 

14. After you have opted to continue, trusting the SSL certificate, you will then be redirected to the administrative login screen, as shown in the following screenshot. However, it will now be using the following secure administrative URL. Note the use of the HTTPS protocol and the port 9043, as shown in the following screenshot:

 

15. Type wasadmin for the username and wasadmin for the password, and click Log in to gain access to the Administrative console.Implementing a file-based repository requires the least effort and can often seem he best way to secure WebSphere. However, being a file-based repository, it means that anyone who has access to the operating system can gain access to the props files containing your usernames and groups and alter the files. Using a file-based repository is not recommended for production. In our next example, we are going to discuss how to use the local operating system as our security manager for users and groups.

Local operating system

We are now going to turn on global security with the Local operating system option, which is the default option in the security configuration wizard.

Linux platforms is not ideal and not the most secure way to run WebSphere in Linux. However, to use the local Linux operating system as a user registry, we need to have WebSphere running as root.

For Windows users, WebSphere must be running under a user with administrative privileges. Since root/administrative access is required for local operating system usage, it means it is not the best method for production environments, because it requires a lower level of administration and is not easily managed. This method can be a good way to secure a local desktop version of WebSphere when you are testing configurations. Using a federated LDAP repository is a better method and more suitable to production-like environments.

This time, in the Global security wizard, select Local operating system on the Secure the application serving environment page and click Next to configure the local operating system. Type wasadmin into the Primary administrative user name field and click Next to review the summary page. Click Finish on the summary page to complete the wizard.

You should now receive the following error message:

 

Creating a Linux user and group

 

By using the addUser Linux command, we can add a new user and password. To create a new user, we must also create an associated group that the user must belong to. The groupadd command is used to create a new group account. The new group will be entered into the system files as required, with appropriate configuration files being updated.

 

There are two types of groups: a primary user group and a secondary group. All user account- related information is stored in /etc/passwd, /etc/shadow, and /etc/group files. Consult the Linux documentation for use of groups.

All Linux OS user accounts must belong to a group. So first, we are going to create a group called was by typing the following command into an SSH session to our Linux box:

/usr/sbin/groupadd was

To create a user, use the useradd command to add a new user and automatically add the user to an existing group (or create a new group and then add the user).

If the group does not exist, create it. The syntax for creating a group is useradd -g {group-name} username. Please note that the small -g option means adding the new user to the initial login group (primary group). The group name must exist. Type the following command to create a new user called wasadmin and add wasadmin to the was group:

/usr/sbin/useradd wasadmin -g was

We can check to see that the user is created by typing the following command:

cat /etc/passwd | cut -d”:” -f1

You will find the user wasadmin listed at the end of the screen output, as a result of executing the previous command.

You now need to run the following command as root, to assign a password to the user named wasadmin:

passwd

The command will prompt you to enter a password; enter wasadmin. The user wsadmin now has this set as their password.

For the WebSphere Application Server Local OS security registry to work on Linux, a shadow password file must exist. The shadow password file is named shadow and is located in the /etc directory. If the shadow password file does not exist, then an error occurs while trying to complete the local OS global security option.

To create the shadow file, run the following Linux command:

pwconv

A /etc/shadow file will be created from the /etc/passwd file. After creating the shadow file, you can continue with the wizard to configure the local operating system security.

 Creating a Windows user

If you have chosen to use Windows, the process of creating a user is much simpler. To create a user called wasadmin, open Windows Computer Management. You can load the Computer Management console by simply right-clicking on the computer icon available in Windows Explorer as shown in the following screenshot:

One you have loaded the Computer Management applet, you can right-click the Users folder which is located in the Users and Group category on the left-hand-side of the applet as shown in the following screenshot:

 

In the New User… dialog, enter wasadmin in the User Name field and wasadmin in the Password and Confirm password fields, as shown in the following screenshot, and check the Password never expires checkbox. Click Create and then Close:

You have now added a local user to the Windows operating system that WAS can use for authentication. Carry on with the security wizard.

Avoid trouble: On Windows, the application server must be started with Administrator privileges if you chose to start WAS using a command prompt. If you start WAS as a service then this is not an issue.

Completing the security wizard

Once you have created a local user and a shadow file using the basic Linux user/group administration, or simple Windows user administration, as outlined previously, we can use this new user’s name in the security wizard and we will be able to complete the wizard’s process.

You may have to start the wizard again if you took too long and the console timed out. If so, restart the local OS global security process using the wizard and remember to save your configuration once you have completed the wizard.

 

Once the Global security wizard is complete, you need to stop and start (bounce) the application server for security to take effect. Once WAS has started backup, we will now be presented with a login screen, which will be the same as in the file-based example previously shown.

We have now learned how to secure a WebSphere Application Server using the local operating system. However, this means that the user will only exist on this physical machine and, in reality, this is not practical in an environment where there are many Linux/Unix or Windows machines running WAS.

Also, you may wish to allow many different types of users to access the console with different rights, and so administration becomes difficult with many users. Using an OS-based authentication method would mean you would be continually updating your local OS with the required user accounts for each separate machine on your network on which WAS is installed.

For security reasons, most Linux/Unix administrators rarely permit processes to run as root. Since most production WAS server processes are not running as the root user, the local OS approach is not practical. It is recommended best practice for WAS Administrators to employ a user directory which can be shared by all WAS servers.

This is why WAS should primarily be configured to use an LDAP (Lightweight Directory Access Protocol) directory. LDAP provides the ability to have a centrally-administrated user and group directory independent from WAS. Using a central user directory allows administration of passwords without worrying about how many server machines have to be updated to allow user management. It can be tedious if you have to go around and update each server’s local user accounts when you want to change your WAS administration password. Common sense dictates that you also don’t want a different password each time you log in to a different instance of WebSphere Application Server.

WebSphere Application Server distinguishes between the user identities for administrators who manage the environment, and server identities for authenticating server-to-server communications. In most cases, server identities are automatically generated and are not stored in a repository.

 

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.