Network Deployment (Distributed operating systems), v8.0 > Tune performance > Tune security > Tune, hardening, and maintaining security configurations


Enablement and migration considerations of Security hardening features

In this release of WAS, more security hardening features of the server are enabled out-of-the-box by default. When migrating, the settings that were enabled prior to migration are retained. However, if the features are not enabled after migration you can enable them yourself.

New feature: To ensure that WAS configuration is set to be secure by default, the following defaults have been changed as part of the new security hardening features in WAS v8.0:

New feature:


Enable the new security hardening features after migration

If the new security features are not enabled after migration, you can enable them yourself using the admin console or by scripting.

Enablement of SSL by default on CSIv2

To enable SSL by default for inbound and outbound transports on CSIv2:

If you are using the admin console, select Security > Global security > RMI/IIOP > CSIv2 inbound communications . In the Transport box, select SSL- required from the pull-down list and then click Apply.

Repeat the same steps for CSIv2 outbound communications and click Security > Global security > RMI/IIOP > CSIv2 outbound communications . In the Transport box, select SSL- required from the menu list and then click Apply.

If you want to enable SSL by default for inbound and outbound transports on CSIv2 using scripting, use the configureCSIInbound and configureCSIOutbound commands. See the Configuring Common Secure Interoperability authentication using scripting topic for more information.

For the client side, edit the sas.client.props file. Change com.ibm.CSI.performTransportAssocSSLTLSRequired to true and change com.ibm.CSI.performTransportAssocSSLTLSSupported to false.

Enablement of the HttpOnly cookie attribute

To enable the HttpOnly attribute on cookies attribute by default:

If you are using the admin console, click Security > Global security > Custom properties . ClickNew and enter com.ibm.ws.security.addHttpOnlyAttributeToCookies for the Name and true for the Value.

We can also enable the HttpOnly attribute using the admin console by clicking Security > Global security > Single sign-on (SSO) . Click Set security cookies to HTTPOnly to help prevent cross-site scripting attacks, and then click Apply.

To enable the HttpOnly attribute on cookies attribute by default using scripting, use the setAdminActiveSecuritySettings command.

Enablement of session security integration

To enable session security integration for each server by using the admin console, select Servers > Server types > WebSphere application servers > server1 > Session management. Select the security integration check box.

To enable persisting credentials from the admin console, click Security > Global security > Web and SIP security > General settings. Select the Use available authentication data when an unprotected URI is accessed check box.


Security hardening features enablement troubleshooting

When the new security hardening features are enabled you might see some differences in system behavior depending upon which environment you might have used in the past.

For example, if you are coming from an environment where CSIv2 transport was set to the previous default of SSL-supported, you do not experience any differences, as SSL-supported communicates with both TCP/IP and SSL connections. If a problem is encountered, however, certificates might not have been exchanged correctly to enable the client and server to communicate. Read about the Secure communications using SSL topic for more information.

If you worked in an environment where TCP/IP is used for the connection to CSIv2, you might experience connection problem to the SSL-enabled CSIv2 connection. The server configuration can be modified to SSL-supported or to TCP/IP if SSL is not required.

For the HttpOnly attribute, when the attribute is added to the security cookies, the browser prevents client side scripts from accessing these cookies. In most case this should be the default behavior to minimize cross-site scripting vulnerabilities. If there is an absolute need to allow client-side scripts to access WebSphere security cookies, and you are aware of the possible consequences, then the setting of the HttpOnly attribute can be disabled.

However, the HttpOnly attribute can possibly uncover client-side scripts that are used to access WebSphere cookies, and can then use them even though it was not intended to do so. If this happens, the web application that enables the scripts to access the WebSphere cookies must be evaluated.

For session security integration enablement, when session integrated security is enabled you might receive an UnauthorizedSessionRequestException exception on servlets if they access a session that belongs to authenticated identities other than to the identity that currently owns the session. If you do not want this checking to occur, you can disable session security from the server that is experiencing the problem.
Secure communications using SSL
Configure Common Secure Interoperability authentication using scripting
Tune, hardening, and maintaining security configurations


Related


Session security support
Security custom properties
Web authentication settings

+

Search Tips   |   Advanced Search