What is new for security specialists

What is new for security specialists

+
Search Tips | Advanced Search

WAS v6.1 contains many new and changed features for those who are responsible for securing applications and the application serving environment.
Deprecated and removed features describes features that are being replaced or removed in this or future releases.

Ease of use

Administrative security enabled out of box
New in V6.1! Access to the administrative system and its data is now protected by default. When creating a profile, whether during or after installation, you will be prompted whether to keep the default. The default is for administrative security to be enabled with the file based user repository as the user registry. The file based repository is implemented using virtual member manager.
Rest assured that if you are migrating from a prior product version, the existing security configuration will be preserved.
Simplified security configuration and administration New in V6.1!

Simplified console security panels
New security wizard
Security configuration reporting tool

Automatically generated server IDs
New in V6.1! This version distinguishes between the user identities for administrators who manage the environment and server identities for authenticating server to server communications. In most cases, server identities are automatically generated and are not stored in a repository. You can change the ID if you like.
You no longer need to specify a server user ID and password during security configuration, unless using a mixed cell environment. To maintain backwards compatibility, specify the server user ID.
Simplified WebSphere key and certificate management New in V6.1! Simplified WebSphere key and certificate management has been added to:

Allow you to use the key management tools from the console
Make it easier to configure SSL attributes
Manage Web server and plug-in certificates from the console
Use the TrustManager to automatically trust hosts or signers
Make it easier to refresh an expiring certificate

Federate various repositories, so you can manage them as one
New in V6.1! Inclusion of virtual member manager in this release provides a single model for managing organizational entities. You can configure a realm that consists of identities in the file-based repository that is built into the system, in one or more external repositories, or in both the built-in, file-based repository and in one or more external repositories.
Currently most WAS applications have their own models and components for managing organizational entities, and they provide different levels of security. Most applications are dependent on specific types and brands of repositories, assume a specific schema for the data in those repositories, and are not able to use repositories with existing data. Virtual member manager helps these applications by providing them a common model, secure access to various brands and types of repositories, and the ability to use repositories with existing data. The single model includes a set of organizational entity types and their properties, a repository-independent API and a Service Provider Programming Interface (SPI) for plugging in repositories. XPath is chosen as the search language in the API and SPI.

Standards support and interoperability

SPNEGO support for single sign-on authentication through Windows desktop
New in V6.1! The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol allows flowing Kerberos tokens from web browsers such as Mozilla FireFox or Microsoft Internet Explorer. This enables seamless single-sign-on experiences on Windows desktops with web browsers that support SPNEGO.
Interoperability with other vendors on WS-Security
New in V6.1! WAS now supports the WS-I Basic Security Profile 1.0, which promotes interoperability by addressing the most common problems encountered from implementation experience to date.
Common Criteria Assurance Level 4 security
WAS has been enhanced to provide Common Criteria Assurance Level 4 security functionality, with full certification available in 2007. Common Criteria is a scheme for independent assessment, analysis, and testing of IT products to a set of security requirements. Certification gives customers the confidence that products will be effective in delivering security functions such as identification and authentication, user data protection, audit, and cryptographic support. Customers gain assurance that the security functions are correctly implemented and will be effective in satisfying their security objectives.
Full FIPS compliance
WAS has been enhanced to support an implementation of the Federal Information Processing Standards (FIPS) 140-2 government standard. The IBM Java Secure Sockets Extension (JSSE) FIPS 140-2 Cryptographic Module for multi-platforms is a scalable, multipurpose Secure Sockets provider that supports cipher suites via the Java 2 application programming interfaces (APIs) for enhanced protection of sensitive data. It enables the product and other IBM products to run in FIPS mode and help fulfill end-to-end requirements for use of FIPS-certified cryptographic module.
JCA 1.5 support
WAS V6.0.x supports the J2EE Connector architecture (JCA) V1.5 specification, which provides new features such as the inbound resource adapter. For more information, see Resource adapters.
From a security perspective, WAS V6.0.x provides an enhanced custom principal and credential mapping programming interface and custom mapping properties at the resource reference level. The custom JAAS login module, which was developed for JCA principal and credential mapping for WAS V5.x, is still supported.
Web services security
A pluggable architecture increases the extensibility of Web services security. The implementation includes many of the features that are described in the Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security V1 standard. As part of this standard, WAS supports custom, pluggable tokens that are used for signing and encryption, pluggable signing and encryption algorithms, pluggable key locators for locating a key that is used for digital signature or encryption, signing or encrypting elements in a SOAP message, and specifying the order of the signing or encryption processes.
Messaging security
For security changes pertaining to service integration, search the information center for the key word: cjr0420.
When administrative security is enabled, the default behavior is for a secure bus to use secure transport protocols. To connect to a secure bus, a user must explicitly be granted the bus connector role. The default bootstrap endpoint is enhanced to use BootstrapSecureMessaging rather than BootstrapBasicMessaging.

Web authentication improvements

Separate Web authentication and authorization
New in V6.1! Now, Web authentication can be performed with or without Web authorization, and Web client’s authenticated identity is available whether or not Web authorization is required. An authenticated identity is persisted both for protected and unprotected resources. Without the separation of Web authentication and Web authorization, a Web authenticated identity is not available when Web authorization is not required, and programmatic security can not work independently without container declarative security.
Enhanced control over Web authentication behavior
New in V6.1! WAS provides enhanced control over the authentication behavior for a Web client. Depending upon the option that you select, WAS can retain the authentication data for future use. Also, when you use certificate authentication and authentication fails, you can enable the Application Server to challenge the Web client for a user ID and password.
Portlet URL security
New in V6.1! WAS enables direct access to portlet Uniform Resource Locators (URLs), just like servlets. For security purposes, portlets are treated similar to servlets. Most portlet security uses the underlying servlet security mechanism. However, portlet security information resides in the portlet.xml file, while the servlet and JavaServer Pages files reside in the web.xml file. Also, when you make access decisions for portlets, the security information, if any, in the web.xml file is combined with the security information in the portlet.xml file. Portlet security must support both programmatic security, that is isUserInRole, and declarative security
Web authentication using the JAAS programming model
WAS V6.0.x enables you to use the JAAS programming model to perform Web authentication in your application code. To use this function, create your own JAAS login configuration by cloning the WEB_INBOUND login configuration and define a cookie=true login option. After a successful login using your login configuration, the Web login session is tracked by SSO token cookies. This option replaces the SSOAuthenticator interface, which was deprecated in WAS V4.

Expanded capabilities

Larger variety of administrative roles
New in V6.1! Even more administrative roles are defined to provide degrees of authority that are needed to perform certain administrative functions from either the Web-based console or the system management scripting interface. The newest roles are Deployer and AdminSecurityManager, available through administrative scripting (wsadmin).
Fine grained administrative role authorization
New in V6.1! In prior releases, users granted administrative roles could administer all of the resource instances under the cell. Now the product is more fine-grained, meaning that access can be granted to each user per resource instance.
Hardware cryptographic device support for Web services security
New in V6.1! Web services security now supports the use of cryptographic hardware devices in two different ways. The hardware cryptographic device can be used to accelerate the cryptographic operations. Also, cryptographic keys can be stored on the hardware cryptographic device and never leave the device.
Custom password encryption
A plug point for custom password encryption must be created to encrypt and decrypt all passwords in WAS that are currently encoded or decoded using Base64-encoding. The implementation class of this plug point has the responsibility for managing keys, determining the encryption algorithm to use, and for protecting the master secret.
Enhanced LDAP support
In addition to support for multiple LDAP directory services binding and failover, you can dynamically update LDAP binding information without first stopping and restarting appservers.
Programming interfaces for implementing identity assertion with trust validation
If you want an application or system provider to perform an identity assertion with trust validation, it can be accomplished by use of the JAAS login framework, where trust validation is performed in one login module and credential creation in another. These two custom login modules are used to create a JAAS login configuration that performs a login to an identity assertion.
Java 2 security manager
WAS V6.0.x provides you with greater control over the permissions granted to applications for manipulating non-system threads. You can permit applications to manipulate non-system threads using the was.policy file. However, these thread control permissions are disabled by default.
SSL channel framework
The Secure Sockets Layer channel framework incorporates the new IBMJSSE2 implementation and separates the security function of Java Secure Sockets Extension (JSSE) from the network communication function.

Sub-topics
Common Criteria (EAL4) support
Federal Information Processing Standard support
Identity management capabilities

Related concepts
Overview and new features for securing applications and their environment

Administrative security enabled out of box	New in V6.1! Access to the administrative system and its data is now protected by default. When creating a profile, whether during or after installation, you will be prompted whether to keep the default. The default is for administrative security to be enabled with the file based user repository as the user registry. The file based repository is implemented using virtual member manager. Rest assured that if you are migrating from a prior product version, the existing security configuration will be preserved.
Simplified security configuration and administration	New in V6.1! Simplified console security panels New security wizard Security configuration reporting tool
Automatically generated server IDs	New in V6.1! This version distinguishes between the user identities for administrators who manage the environment and server identities for authenticating server to server communications. In most cases, server identities are automatically generated and are not stored in a repository. You can change the ID if you like. You no longer need to specify a server user ID and password during security configuration, unless using a mixed cell environment. To maintain backwards compatibility, specify the server user ID.
Simplified WebSphere key and certificate management	New in V6.1! Simplified WebSphere key and certificate management has been added to: Allow you to use the key management tools from the console Make it easier to configure SSL attributes Manage Web server and plug-in certificates from the console Use the TrustManager to automatically trust hosts or signers Make it easier to refresh an expiring certificate
Federate various repositories, so you can manage them as one	New in V6.1! Inclusion of virtual member manager in this release provides a single model for managing organizational entities. You can configure a realm that consists of identities in the file-based repository that is built into the system, in one or more external repositories, or in both the built-in, file-based repository and in one or more external repositories. Currently most WAS applications have their own models and components for managing organizational entities, and they provide different levels of security. Most applications are dependent on specific types and brands of repositories, assume a specific schema for the data in those repositories, and are not able to use repositories with existing data. Virtual member manager helps these applications by providing them a common model, secure access to various brands and types of repositories, and the ability to use repositories with existing data. The single model includes a set of organizational entity types and their properties, a repository-independent API and a Service Provider Programming Interface (SPI) for plugging in repositories. XPath is chosen as the search language in the API and SPI.

SPNEGO support for single sign-on authentication through Windows desktop	New in V6.1! The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) protocol allows flowing Kerberos tokens from web browsers such as Mozilla FireFox or Microsoft Internet Explorer. This enables seamless single-sign-on experiences on Windows desktops with web browsers that support SPNEGO.
Interoperability with other vendors on WS-Security	New in V6.1! WAS now supports the WS-I Basic Security Profile 1.0, which promotes interoperability by addressing the most common problems encountered from implementation experience to date.
Common Criteria Assurance Level 4 security	WAS has been enhanced to provide Common Criteria Assurance Level 4 security functionality, with full certification available in 2007. Common Criteria is a scheme for independent assessment, analysis, and testing of IT products to a set of security requirements. Certification gives customers the confidence that products will be effective in delivering security functions such as identification and authentication, user data protection, audit, and cryptographic support. Customers gain assurance that the security functions are correctly implemented and will be effective in satisfying their security objectives.
Full FIPS compliance	WAS has been enhanced to support an implementation of the Federal Information Processing Standards (FIPS) 140-2 government standard. The IBM Java Secure Sockets Extension (JSSE) FIPS 140-2 Cryptographic Module for multi-platforms is a scalable, multipurpose Secure Sockets provider that supports cipher suites via the Java 2 application programming interfaces (APIs) for enhanced protection of sensitive data. It enables the product and other IBM products to run in FIPS mode and help fulfill end-to-end requirements for use of FIPS-certified cryptographic module.
JCA 1.5 support	WAS V6.0.x supports the J2EE Connector architecture (JCA) V1.5 specification, which provides new features such as the inbound resource adapter. For more information, see Resource adapters. From a security perspective, WAS V6.0.x provides an enhanced custom principal and credential mapping programming interface and custom mapping properties at the resource reference level. The custom JAAS login module, which was developed for JCA principal and credential mapping for WAS V5.x, is still supported.
Web services security	A pluggable architecture increases the extensibility of Web services security. The implementation includes many of the features that are described in the Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security V1 standard. As part of this standard, WAS supports custom, pluggable tokens that are used for signing and encryption, pluggable signing and encryption algorithms, pluggable key locators for locating a key that is used for digital signature or encryption, signing or encrypting elements in a SOAP message, and specifying the order of the signing or encryption processes.
Messaging security	For security changes pertaining to service integration, search the information center for the key word: cjr0420. When administrative security is enabled, the default behavior is for a secure bus to use secure transport protocols. To connect to a secure bus, a user must explicitly be granted the bus connector role. The default bootstrap endpoint is enhanced to use BootstrapSecureMessaging rather than BootstrapBasicMessaging.

Separate Web authentication and authorization	New in V6.1! Now, Web authentication can be performed with or without Web authorization, and Web client’s authenticated identity is available whether or not Web authorization is required. An authenticated identity is persisted both for protected and unprotected resources. Without the separation of Web authentication and Web authorization, a Web authenticated identity is not available when Web authorization is not required, and programmatic security can not work independently without container declarative security.
Enhanced control over Web authentication behavior	New in V6.1! WAS provides enhanced control over the authentication behavior for a Web client. Depending upon the option that you select, WAS can retain the authentication data for future use. Also, when you use certificate authentication and authentication fails, you can enable the Application Server to challenge the Web client for a user ID and password.
Portlet URL security	New in V6.1! WAS enables direct access to portlet Uniform Resource Locators (URLs), just like servlets. For security purposes, portlets are treated similar to servlets. Most portlet security uses the underlying servlet security mechanism. However, portlet security information resides in the portlet.xml file, while the servlet and JavaServer Pages files reside in the web.xml file. Also, when you make access decisions for portlets, the security information, if any, in the web.xml file is combined with the security information in the portlet.xml file. Portlet security must support both programmatic security, that is isUserInRole, and declarative security
Web authentication using the JAAS programming model	WAS V6.0.x enables you to use the JAAS programming model to perform Web authentication in your application code. To use this function, create your own JAAS login configuration by cloning the WEB_INBOUND login configuration and define a cookie=true login option. After a successful login using your login configuration, the Web login session is tracked by SSO token cookies. This option replaces the SSOAuthenticator interface, which was deprecated in WAS V4.

Larger variety of administrative roles	New in V6.1! Even more administrative roles are defined to provide degrees of authority that are needed to perform certain administrative functions from either the Web-based console or the system management scripting interface. The newest roles are Deployer and AdminSecurityManager, available through administrative scripting (wsadmin).
Fine grained administrative role authorization	New in V6.1! In prior releases, users granted administrative roles could administer all of the resource instances under the cell. Now the product is more fine-grained, meaning that access can be granted to each user per resource instance.
Hardware cryptographic device support for Web services security	New in V6.1! Web services security now supports the use of cryptographic hardware devices in two different ways. The hardware cryptographic device can be used to accelerate the cryptographic operations. Also, cryptographic keys can be stored on the hardware cryptographic device and never leave the device.
Custom password encryption	A plug point for custom password encryption must be created to encrypt and decrypt all passwords in WAS that are currently encoded or decoded using Base64-encoding. The implementation class of this plug point has the responsibility for managing keys, determining the encryption algorithm to use, and for protecting the master secret.
Enhanced LDAP support	In addition to support for multiple LDAP directory services binding and failover, you can dynamically update LDAP binding information without first stopping and restarting appservers.
Programming interfaces for implementing identity assertion with trust validation	If you want an application or system provider to perform an identity assertion with trust validation, it can be accomplished by use of the JAAS login framework, where trust validation is performed in one login module and credential creation in another. These two custom login modules are used to create a JAAS login configuration that performs a login to an identity assertion.
Java 2 security manager	WAS V6.0.x provides you with greater control over the permissions granted to applications for manipulating non-system threads. You can permit applications to manipulate non-system threads using the was.policy file. However, these thread control permissions are disabled by default.
SSL channel framework	The Secure Sockets Layer channel framework incorporates the new IBMJSSE2 implementation and separates the security function of Java Secure Sockets Extension (JSSE) from the network communication function.