• No replies
1 Post

Pinned topic Feature Focus Week: Security Enhancements in WebSphere V8.0 Beta

‏2010-08-16T19:02:57Z |
The following describes the various security enhancements available in the WebSphere Application Server Version 8.0 Beta.

Java Servlet 3.0 security features

This version of WebSphere supports all security updates as defined in the Java Servlet 3.0 specification (JSR-315), including the new servlet security annotations, the dynamic updating of the servlet security configuration, use of new programmatic security APIs, HTTP method omission and display the realm name for basic authentication login.

Security annotations

Web applications can now define the new @ServletSecurity annotations in the code to control the access to the web resources. This provides an alternate mechanism for defining security constraints equivalent to those that could have been declared in the portable deployment descriptor. When an application is deployed, the security annotations in the code are read by the security runtime. When the web resource is accessed these security constraints are applied just like if they had been declared in the deployment descriptor. For any URL pattern, if the security constraints are defined both through the annotations and the deployment descriptor the constraints in the deployment descriptor take precedence.

Setting access control programmatically

The Servlet 3.0 specification defines the setServletSecurity method within a ServletContextListener that can be used to define the security constraints to be applied to the mappings defined for a ServletRegistration. So during a servlet registration, security constraints can be programmatically established for the resource using the setServletSecurity method.
When an application starts, the web container notifies the security component to inspect all ServletRegistration annotations that have URL patterns and security constraints. The security component then determines if a URL pattern is defined in the deployment descriptor. If an exact match is not already defined in the deployment descriptor, the security constraints set by the setServletSecurity method will be enforced during the access check for that resource.

Support for the authenticate, login and logout servlet security methods

The sevlet 3.0 specification adds the following methods to the HttpServletRequest interface to support programmatic security.
  • The authenticate method authenticates a user by using the WebSphere Application Server container login mechanism configured for the servlet context.

  • The syntax of the authenticate method is as follows: boolean authenticate(HttpServletResponse response)

  • The login method authenticates a user to the WebSphere Application Server with an user name and password.

  • The syntax of the login method is as follows: login(java.lang.String username, java.lang.String password)

  • The logout method logs the user out of the WebSphere Application Server and invalidates the HTTP session.

  • The syntax of the logout method is as follows: logout()

Support http-method-omission element in the application web.xml file

Provides a simpler way to omit http-methods that should not use a set of security constrains in the application web.xml file. When a http-method-omission is configured for an URL pattern any method that is not listed in it will have the security constraints enforced on them.

The following describes the various security enhancements available in the WebSphere Application Server version 8.0 Alpha.

Additional Security Hardening by Default

Additional security features are now being enabled by default . On new installations of WebSphere version 8.0 Beta you will find Common Security Interoperability Version 2 (CSIv2) transport configured to SSL-required, HttpOnly attribute will be added to cookies, and session security will be enabled by default.

When security is enabled to make sure connections in and out of the server use a SSL connection, the CSIv2 transport layer will be set to SSL-required by default. This is a change form the setting of SSL-supported where connection of SSL or non-SSL would be accepted on a CSIv2 connection. If the new default setting is not desired it can be disabled by going to Security > Global security > CSIv2 inbound communications or Security > Global security > CSIv2 outbound communications and change the transport to SSL-supported.

The HttpOnly cookie attribute introduced to as a measure to mitigate cross site scripting vulnerability attacks. When the cookie is present most browsers will not allow cookies to be accessed from a client side script. WebSphere will add the httpOnly attribute to LTPA cookie and the WASReqURL cookies by default. If HttpOnly attributes are not desired they can be disabled by going to Security > Global security > Custom properties on the console and changing the property to false.

Session security will be enabled by default. Once a session is created by a user, only that user can access the session. An UnauthorizedSessionRequestException will returned when an unauthorized resource attempt to access that session. To go along with this the Web authentication settings,, will be set to 'persisting', from 'lazy'. This will allow available authentication data to be used when an unprotected resource is being accessed. If there is a need to disable session security it can be done by going to Application servers > <server name> > Session management and selecting the Security integration box.
To change the Web authentication setting back to lazy go to Security > Global security > Web security - General settings and uncheck the box that says 'Use available authentication data when an unprotected URI is accessed'.

Enhanced Audit Log Handling Options

Security Auditing was introduced in the IBM WebSphere Application Server v7.0 product. A default
implementation, the Binary Audit Log, was provided which allowed auditable events to be gathered and recorded to binary audit logs. Configurable options were provided to define the maximum number of archived logs as well as maximum size of each log.

By default, once the maximum number of archived logs was reached, the oldest binary audit log was rewritten over. This forced the end user to provide an archiving mechanism to ensure there was no loss of archived audit log.

In the WebSphere Application Server V8.0 Beta release, new customizable options are available to define the wrapping behavior of the audit log when using the provided Binary Audit Log implementation. The options are available when configuring the binary file-based emitter in the Admin Console.

The WRAP option, referenced by "overwrite oldest" in the Admin Console, mimics the current behavior in the V7.0 product and is the default selection for V8.0 Beta. Under this option, when the maximum number of archived audit logs is reached, the oldest audit log is rewritten.

If the NOWRAP option, referenced by "stop server" in the Console, is selected, when the maximum number of archived logs is reached, the oldest audit log is not rewritten. Instead, the audit service is stopped, a notification is sent to the SystemOut.log indicating that the audit service has been stopped and the server process which has reached its maximum number of audit logs is gracefully quiesced.

The third option, SILENT_FAIL, referenced by "stop logging" in the console, similarly stops the audit service when the maximum number of archived logs is reached. However, unlike NOWRAP, this option allows the WebSphere process to continue. Notifications that the auditing service has stopped is not posted to the SystemOut.log.

As with V7.0, archiving of audit logs, regardless of the option selected, is still something that the end user needs to consider if a history of audit activity needs to be saved over a long period of time.

With either the NOWRAP or SILENT_FAIL options, when the server is stopped as a result of the maximum number of archived logs being reached, the binary audit logs should be archived prior to restarting the server to allow for the writing of new audit logs.

Enhanced Security Configuration Report

The security configuration report was updated to include a new section called Cookie Protection. It contains the security configuration setting for HttpOnly, Web Authentication settings, Single Signon SSL setting, and the session security integration setting for each server in the configuration.

Additional links to Beta Infocenter material:

For What's New for Security in the Beta, see the What is new for security specialists section of the WebSphere Application Server BETA Information Center.

Ut Le
WebSphere Application Server Security Developer

Ajay Reddy
WebSphere Application Server Security Technical Team Lead

Updated on 2010-08-17T00:10:51Z at 2010-08-17T00:10:51Z by