Secure specific appservers

We can customize security to some extent at the appserver level. We can disable admin security on an appserver.

Deprecated feature: Server level security has been deprecated in this release of WAS. Multiple security domain support has been added in its place. We can create different security configurations and assign them to different applications in WAS processes. By creating multiple security domains, we can configure different security attributes for both admin and user applications within a cell environment. Configure different applications to use different security configurations by assigning the servers or clusters or SIBuses that host these applications to the security domains. Read about Multiple security domains for more detailed information.depfeat

We can also modify Java2 Security and some of the other security attributes that are found on the Global security panel. This panel provides access to the cell-level security settings. We cannot configure a different authentication mechanism or user registry on an individual server basis. This feature is limited to cell-level configuration only.

By default, server security inherits all of the values that are configured for cell-level security. To override the cell-level security configuration at the server level ...

Servers > Application Servers > myserver. Under Security, click Server Security and click any of the following links:

• CSIv2 inbound authentication

• CSIv2 outbound authentication
• CSIv2 inbound transport

• CSIv2 outbound transport

• SAS inbound transport

• SAS outbound transport

• Server-level security

SAS is supported only between V6.0.x and previous version servers that have been federated in a V6.1 cell.

After modifying the configuration in any of these panels and clicking OK or Apply, the security configuration for that panel or set of panels now overrides cell-level security. Other panels that are not overridden continue to be inherited at the cell-level. However, we can always revert back to the cell-level configuration at any time. We can revert back to the cell-level security configuration by clearing the check box next to any of the following options on the Server security panel:

• Security settings for this server override cell settings
• RMI/IIOP security for this server overrides cell settings

• SAS security for this server overrides cell settings

See Server and admin security.

 

1. Start the admin console for the dmgr.

   To get to the admin console, go to http://host.domain:port_number/ibm/console. If security is disabled, we can enter any ID. If security is enabled, enter a valid user ID and password, which is either the administrative ID configured for the user registry or a user ID that is entered as an admin user. To add a user ID as an admin user, click System Administration > Console settings > Console users.

2. Set cell-level security if we have not configured it previously.

   Go to Enable security for detailed steps. After security is configured, configure server-level security.

   Server-level security is not enabled when you select the Enable application security option on the Server-level security settings of the admin console. We also must enable cell-level security by selecting the Enable admin security option on the Global security settings panel of the admin console.

3. To configure server-level security ...

   Servers > Application Servers > server name. Under Security, click WAS security.

   The status of the security level that is in use for this application server is displayed.

   By default, we can see that the cell-level security configuration, Common Secure Interoperability (CSI), and SAS have not been overridden at the server level. CSI and SAS are authentication protocols for RMI/IIOP security requests. The server-level security panel lists attributes that are on the Global security panel and can be overridden at the server level. Not all of the attributes on the Global security panel can be overridden at the server level, including the user account repository.

4. To enable admin security for this appserver, go to the Server-level security panel, select the Security settings for this server override cell settings and the Enable application security options.

   By modifying the Server-level security panel, these settings override the settings for cell-level security.

5. Click Apply and Save.

6. To enable RMI/IIOP security for the appserver, go to the Server-level security panel, select the RMI/IIOP security for this server overrides cell settings option and click Apply. If we select the RMI/IIOP security for this server overrides cell settings option, any changes that you make to the CSIv2 authentication or transport settings override the same settings on the cell level.

 

Next steps

Typically, server-level security is used to disable user security for a specific appserver. However, this can also be used to disable or enable the Java 2 security manager, and to configure the authentication requirements for RMI/IIOP requests both incoming and outgoing from this application server.

After you modify the configuration for a particular application server, restart the appserver for the changes to become effective. To restart the appserver, go to Servers > Application servers and click the server name that you recently modified. Click Stop and then Start.

If we disabled security for the appserver, we can typically test a Web address that is protected when security is enabled.

One URL that usually is installed when the DefaultApplication during installation is the snoop application. If the DefaultApplication is installed on the appserver, test that security is disabled by going to the following URL: http://host.domain:9082/snoop. If security is disabled, a prompt does not display. This URL is just one method of validating the configuration. Validate that the configuration is appropriate for the applications.

Server-level security settings

 

Related concepts

Multiple security domains

 

Related tasks

Set up, enabling and migrating security