Network Deployment (Distributed operating systems), v8.0 > New features > Overview and new features: Securing

What is new for security specialists

This version contains many new and changed features for those who are responsible for securing applications and the application serving environment.

• Audit service provider settings

  • In this release of WAS, there are new customizable options available when specifying the default audit log wrapping behavior. This is only applicable to the Binary Audit Log implementation.

    Choose from one of the following options:

    WRAP

    If you select this option, when the maximum audit logs are reached, the oldest audit log is rewritten; notification is not sent to the auditor. This is the default option, and mimics the default behavior in WAS v7.0.

    NOWRAP

    This option does not rewrite over the oldest audit log. It stops the audit service, sends a notification to the SystemOut.log, and quiesces the application server.

    SILENT_FAIL

    This option does not rewrite over the oldest audit log. It also stops the audit service, but does allow the WebSphere process to continue. Notifications are not posted in the SystemOut.log.

    If audit notification of failures in the audit subsystem is configured, and SILENT_FAIL is selected, the auditor is not notified of the audit subsystem failure. The SILENT_FAIL option takes precedence

    If you use the NOWRAP or SILENT_FAIL options, when the server is stopped as a result of the logs being maxed-out, a stopserver is performed, or because the server abends in some way, archive the binary audit logs before you restart the server.

• Enablement and migration considerations of Security hardening features

  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:

  • Enablement of SSL-required on Common Secure Interoperability version 2 (CSIv2) transport by default

    The following settings for the CSIv2 transport layer exist: TCP/IP for a TCP/IP connection, SSL-supported for a TCP/IP or an SSL connection, and SSL-required for an SSL connection only. SSL-required is the new default in this release of WAS. Switching to SSL-required as the default setting ensures that all CSIv2 connections into and out of the server are using the secure SSL connection.

  • Enablement of the HttpOnly attribute on LTPA cookies by default

    When the com.ibm.ws.security.addHttpOnlyAttributeToCookies custom property is set to true, the HttpOnly attribute is added to those security cookies (LTPA and WASReqURL cookies) that are created by the server. The HttpOnly attribute is a browser attribute created to prevent client side applications (such as Java scripts) from accessing cookies to prevent some cross-site scripting vulnerabilities. This attribute is now configurable in the administrative console. Prior to WAS v8.0, the com.ibm.ws.security.addHttpOnlyAttributeToCookies custom property default was false. For WAS v8.0, the default is now true for both the LTPA cookie and the Session Cookie.

    For more information see the custom property com.ibm.ws.security.addHttpOnlyAttributeToCookies in the Security custom properties article.

  • Enablement of session security integration by default

    Only authenticated users can access sessions created in secure pages. The session management facility uses the security infrastructure to determine the authenticated identity associated with a client HTTP request, and either retrieves or creates a session. For more information on session security, read the Session security support article.

    Along with enabling session security integration, credential persistence is enabled as well. This allows login information to be available to unprotected web clients to enable additional access to user information. For more information on credential persistence, see the "Use available authentication data when an unprotected URI is accessed" feature in the web authentication settings article.

• Implement a custom authentication provider using JASPI

  This release of WAS supports the JSR 196: Java Authentication SPI for Containers (JASPI, or sometimes called JASPIC) specification, which enables third-party security providers to handle the Java EE authentication of HTTP request and response messages destined for web applications. The JASPI specification extends the pluggable authentication concepts of the JAAS to the authentication of HTTP request and response messages. When application security is enabled, and a protected web resource is accessed, the web container and the security runtime collaborate to make an authentication decision for the caller. When using a third-party JASPI provider, the authentication decision is delegated to that provider.

• Java Servlet 3.0 support for security

  This release of WAS supports all security updates as defined in the Java Servlet 3.0 specification (JSR-315), including the new servlet security annotations, use of new programmatic security APIs and the dynamic updating of the servlet security configuration.

  A significant enhancement is the new annotation support for servlets. A developer can declare the security constraints using annotations as an alternative to declaring them as part of the web.xml file, which is used prior to Java Servlet 3.0. The web.xml file continues to function and overrides any conflicts defined as annotations.

  The list of supported Java Servlet 3.0 updates for security includes the following:

  • Support for the @ServletSecurity annotation
  • Support for the dynamic updating of the @RunAs, @declareRoles, and @ServletSecurity servlet security annotations
  • Support for the authenticate, login and logout servlet security methods
  • The new com.ibm.websphere.security.displayRealm property specifies whether the HTTP basic authentication login window displays the realm name that is not defined in the application web.xml file.

• LTPACommandGroup command group

  Use the importLTPAKeys command to import an LTPA key from a file and add it to the security runtime and configuration. The exportLTPAKeys command exports an LTPA key that is currently being used by the runtime to a file.

• Multiple security domains

  In WAS v7.0, the federated repositories user registry can only be configured at the global level and have only one instance per cell, but any domain can use it by configuring it as the active registry. In WAS v8.0, you can configure a unique instance of a federated repository at the domain level in a multiple security domain environment.

  When a security domain is copied from the global level, the users and groups defined at the global level are also copied to the security domain. This is also true when copying from an existing domain. A newly-created security domain that uses the file-based VMM repository requires that the user populate the repository with users and groups.

  Also new in this release of WAS, a new checkbox on the Realm configurations settings administrative console page, Use global schema for model, sets the global schema option for the data model in a multiple security domain environment. Global schema refers to the schema of the admin domain.

• Security configuration report

  The security configuration report now includes information about session security, web Attributes, and the HttpOnly setting to enable you to get a more complete view of your server security settings.

  The report is a table with four columns: Console Name, Security Configuration Name, Value and Console Path Name. The security information gathered is divided into sections, and groups common security information. A row highlighted in blue with a title in the first column starts a new section.

  The Security Configuration Report can be run from the administrative console by selecting Security > Global Security and then clicking Security Configuration Report. A new window displays the report information.

• Security custom properties

  New for this release, the default value of the com.ibm.CSI.propagateFirstCallerOnly security custom property is set to true. When this custom property is set to true, the first caller in the propagation token that stays on the thread is logged when security attribute propagation is enabled. When this property is set to false, all of the caller switches are logged, which can affect performance.

• Single sign-on settings

  The Set security cookies as HTTPOnly to resist cross-site scripting attacks check box has been added to the Single sign-on settings page for this release. The HttpOnly attribute is a browser attribute created to prevent client side applications (such as Java scripts) from accessing cookies to prevent some cross-site scripting vulnerabilities. The attribute specifies that LTPA and WASReqURL cookies include the HTTPOnly field.

• Use a WAS API to achieve downstream web single sign-on with an LtpaToken2 cookie

  Web applications running in mid-tier WebSphere servers might need to propagate LtpaToken2 cookies on downstream web invocations. In this release of WAS, a new API is provided for application developers to programmatically perform downstream SSO without the need for an application to store and send user credentials.

+

Search Tips   |   Advanced Search