Securing The Administrative Console and Applications For WebSphere

Registries and Repositories

With the IBM WebSphere Application Server, a user registry, or repository, authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. WebSphere makes access control decisions based on the information stored in the user registry or repository.

WebSphere supports multiple types of registries and repositories, including:

• Local operating system registry.

• Standalone lightweight directory access protocol (LDAP) registry.

• A standalone custom registry.

• Federated repositories.

Security Domains

WebSphere allows "fine-grained security configuration" enabling security to be configured at the cell, node, server, or cluster level. Also, with WebSphere, you can configure application security separately for administrative security within a cell environment. Administrative security can be enabled through Global Security, while application security can be enabled by creating a new Security Domain and customizing the security configurations specific to the domain.

You configure separate applications to use different security configurations by assigning the servers, cluster, or Service Integration Buses hosting the applications or servlets to appropriate security domains.

For example, administration can be configured to use a federated repository while the applications can be configured to use an LDAP registry. In previous versions of Websphere, administrative and user applications use global security attributes by default, where a user registry defined in global security authenticates users for every application in the cell. Using multiple security domains provides more flexibility and simpler configurations.

This section illustrates how you can configure application security separately by creating a new security domain and assign it to the server level scope. The Administrative Console is secured with global security settings. The primary admin user belongs to the Local Operating System registry realm. The Report Repository Servlet of the PeopleTools application is secured by providing access to a user from another realm.

Configuring Administrative Security

To configure Administrative Security:

1. Open the Administrative Console of the profile hosting the PeopleSoft application.

2. Select Security, Global Security.

3. In the User account repository group box, set Available realm definitions to Local operating system, and click Configure.

4. In the Primary administrative user name field, enter a valid user name.

   In this example "ansrivat11" will be the admin user ID. This value is the name of a user with administrative privileges that is defined in the registry. This user name is used to access the Administrative Console or used by wsadmin. On UNIX this should be “root” user.

5. Select the Server User Identity that is stored in the repository radio button, and enter the same user name as mentioned above for Server user ID or administrative user on version WAS 6.x node field, and enter the user’s password that corresponds to server identity.

6. In the Custom properties table, click New, and enter these values:

   Name: com.ibm.websphere.registry.UseRegistry

   Value: local

7. Click Apply and Save.

8. Select Security, Global Security and click the Administrative user roles link, ensure that the user ID you just specified as the Primary administrative user name appears assigned to the Primary administrative user name role.

9. Return to Security, Global security and set these options:

   1. Select the Enable administrative security check box.

   2. Select the Enable application security checkbox only if you want the application security to have the same global security configuration as the admin user. In this example, we illustrate the application security enabled separately within a separate domain.

   3. Deselect the Java 2 security options. PeopleSoft does not adhere completely to Java 2 security.

   4. Click Apply.

Configuring SSL

If you are using the default SSL configuration, extract the signer certificate from the WebSphere default Trust Store. If you have set up a customized SSL configuration extract the signer certificate corresponding to that configuration.

To configure SSL:

1. In the Administrative Console select Security, SSL certificates and key management.

2. Under Related Items, click Key stores and certificates.

3. Click NodeDefaultTrustStore.

4. Click Signer certificates.

5. Select Root signer and click Extract.

6. Enter a unique path and filename for the signer, such as c:\temp\rootsigner.arm.

7. Click OK.

8. Add the exported signer certificate to trust.p12 in the <PS_HOME>/webserv/<profile name>/etc directory to enable SSL connectivity.

   1. Open the key management utility, iKeyman, for that product version.

   2. Start ikeyman.bat or ikeyman.sh from <PS_HOME>/webserv/<profile name>/bin.

   3. Select Key Database File, Open.

   4. Open <PS_HOME>/webserv/<profilename>/etc/trust.p12.

   5. Enter WebAS for the password. (Do not change this password.)

   6. Select Add and enter the path to the signer certificate you extracted.

9. Log out from the Administrative Console and stop the web server.

Modifying soap.client.props File

In any text editor, open the soap.client.props file located in PIA_HOME\webserv\<profile name>\properties. Set securityEnabled to true, and specify the appropriate user ID and password for loginUserID and loginPassword. For example,

com.ibm.SOAP.securityEnabled=true

com.ibm.SOAP.loginUserid=<user ID>
com.ibm.SOAP.loginPassword=<password>

Use the user ID and password used to access the Administrative Console. If you want to encode the password in this file then run the PropFilePasswordEncoder script located in the folder PS_HOME/webserv/<profileName>/bin. For example,

PropFilePasswordEncoder.sh PS_HOME/webserv/<profileName>
/properties/soap.client.props com.ibm.SOAP.loginPassword

Testing Administrative Console Security

Successfully starting the WebSphere Application Server and successfully logging into the Administrative Console verifies that Admin Security is enabled.

To test Administrative Console security:

1. Start the server.

2. Launch the Administrative Console.

3. When prompted to log in, submit the user ID and password you configured previously.

4. To ensure no PeopleSoft elements have been changed, sign on to PIA as well.

Modifying and Deploying the Delivered EAR file

In this procedure, you modify the delivered peoplesoft.ear file and deploy it using the PeopleSoft install program.

To modify and deploy peoplesoft,ear:

1. Locate the PeopleSoft ear file and move it to a temporary directory.

   Copy the PeopleSoft application ear file (peoplesoft.ear) from PS_HOME\setup\PsMpPIAInstall\archives folder into a temporary directory and extract it. In this discussion, C:\temp is used.

2. Modify the application.xml file and add the <security_role> element as shown below.

   1. Open C:\temp\META-INF\application.xml.

   2. Add the security section shown below:

      <application>
      ...
      ...
      ...
      <module>
      <web>
      <web-uri> helloportletapp.war</web-uri>
      <context-root /helloportletapp</context-root>
      </web>
      </module>
      <security-role>
      <description>Role for SchedulerTransfer Servlet</description>
      <role-name>SchedulerTransferRole</role-name>
      </security-role>
      </application>
      

   3. Save and close the file.

3. Modify the PORTAL web.xml file.

   1. Extract C:\temp\PORTAL.war to C:\temp\PORTAL directory.

   2. Open C:\temp\PORTAL\WEB-INF\web.xml.

   3. Add the <security-constraint> and <security-role> element after the <welcome-file-list> element, and before the </web-app> element. In this case, the SchedulerTransferRole is mapped to the resource Report Repository servlet.

      ...
      </welcome-file-list>
      <security-constraint>
      <web-resource-collection>
      <web-resource-name>SchedulerTransferWebResource</web-resource-name>
      <description>SchedulerTransferWebResourceDescription</description>
      <url-pattern>/SchedulerTransfer/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
      <description></description>
      <role-name>SchedulerTransferRole</role-name>
      </auth-constraint>
      </security-constraint>
      <security-role>
      <description></description>
      <role-name>SchedulerTransferRole</role-name>
      </security-role>
      </web-app>
      

   4. Save and close the file.

4. Recreate PORTAL.WAR.

   1. Repackage PORTAL.war by running the following command

      cd C:\temp\PORTAL
      jar -cvf ..\PORTAL.war *
      

   2. Delete the C:\temp\PORTAL directory.

5. Repackage the peoplesoft.ear file by running the following command in the temporary directory.

   jar -cvf ..\peoplesoft.ear *

6. Copy the recreated ear file into PS_HOME\setup\PsMpPIAInstall\archives.

7. Deploy the recreated ear file onto WebSphere using the PeopleSoft Internet Architecture installation program.

Create a New Security Domain For Application Security

Creating a separate security domain for applications enables you to assign tailored security attributes to the application.

To create a security domain:

1. Select Security, Security domains, and click New.

2. Provide a name and description for the security domain, and click OK.

3. Define the scope.

   For this example, the scope is server1, but other implementations can set the scope at Cell, Clusters, Nodes, and so on.

4. Under Security Attributes, expand Application Security and select the Customize for this domain radio button, and select the Enable application security check box.

5. Expand User Realm, and select Customize for this domain, select a Realm type, and click Configure.

   In this example, Local operating system is used, but any of the realm types can be used. The realm selected will need to contain the users who are authorized to access the resource, which in this case is the Report Repository servlet.

   For this example, when configuring the realm, we use appRealm for the Provide a realm name field. In the Custom properties table we use com.ibm.websphere.registry.UserRegistry (Name) and local (Value).

Mapping Security Roles to User Groups

To map security roles to user groups:

1. Select Applications, Application Types, WebSphere enterprise applications, and click peoplesoft.

2. Click Security role to user/group mapping.

3. Select SchedulerTransferRole and click on Map Users.

4. Select the User realm as the one created for the application, in this case it is the "appRealm".

5. Click the Search button to display all the available user IDs for this realm.

   For this example, we select the user ID ansrivat12 for the SchedulerTransferRole. This ensures that only the user ansrivat12 is authorized to access the Report Repository servlet.

Testing Application Security

Restart the web server. Test the security of Report Repository servlet (as we configured it in this example) by using the following URL:

http(s)://<hostname>:<PIA http(s) port>/SchedulerTransfer/ps

You should be prompted for user ID and Password dialog. If authentication is successful, you should be shown the servlet output.