The following information provides an overview of security in WebSphere Application Server. IBM WebSphere Application Server provides security infrastructure and mechanisms to protect sensitive J2EE resources and administrative resources. It also addresses enterprise end-to-end security requirements on:
IBM WebSphere Application Server security is based on industry standards and has an open architecture that ensures secure connectivity and interoperability with Enterprise Information Systems (EIS) including:
WebSphere Application Server also supports other security providers including:
IBM WebSphere Application Server provides a unified, policy-based, and permission-based model for securing Web resources, Web service endpoints, and enterprise JavaBeans according to J2EE specifications. Specifically, WebSphere Application Server complies with J2EE specification V1.4 and has passed the J2EE Compatibility Test Suite. WebSphere Application Server security is a layered architecture built on top of an operating system platform, a JVM, and Java 2 security. This security model employs a rich set of security technology including the:
![[This information applies to V6.0.x and previous servers only that are federated in a V6.1 cell.]](../../v6app.gif)
Common Secure Interoperability V2 (CSIv2) security
protocol, in addition to the Secure Authentication Services (SAS) security
protocol. Both protocols are supported by prior WebSphere Application Server
releases. CSIv2 is an integral part of the J2EE 1.4 specification and is essential
for interoperability among application servers from different vendors and
with enterprise CORBA services.
SAS is supported only between V6.0.x and previous version servers that have been federated in a V6.1 cell.
The standard security models and interfaces that support secure socket communication, message encryption, and data encryption are the Java Secure Socket Extension (JSSE) and the Java Cryptographic Extension (JCE).
An application server plays an integral part in the multiple-tier enterprise computing framework. IBM WebSphere Application Server adopts the open architecture paradigm and provides many plug-in points to integrate with enterprise software components. Plug-in points are based on standard J2EE specifications wherever applicable.
The dark blue shaded background indicates the boundary between the WebSphere Application Server V6 and other business application components. WebSphere Application Server provides Simple WebSphere Authentication Mechanism (SWAM) and Lightweight Third Party Authentication (LTPA) mechanisms. Exactly one authentication mechanism can be configured to be the active authentication mechanism for the security domain of WebSphere Application Server. Exactly one user registry implementation can be configured to be the active user registry of WebSphere Application Server security domain. WebSphere Application Server provides the following user registry implementations: UNIX, Windows, and i5/OS local OS and Lightweight Directory Access Protocol (LDAP). It also provides file-based and Java database connectivity (JDBC)-based user registry reference implementations. It supports a flexible combination of authentication mechanisms and user registries. SWAM is simple to configure and is useful for a single application server environment. LTPA generates a security token for authenticated users, which can propagate to downstream servers and is suitable for a distributed environment with multiple application servers. It is possible to use SWAM in a distributed environment if identity assertion is enabled. The identity assertion feature is available only on the CSIv2 security protocol.
Note: SWAM is deprecated in WebSphere Application Server V6.1 and will be removed in a future release.
The LTPA authentication mechanism is designed for distributed security. Downstream servers can validate the security token. It also supports setting up a trust association relationship with reverse secure proxy servers and single sign-on (SSO), which is discussed later. Besides the combination of LTPA and LDAP or Custom user registry interface, V5.x or V6 supports LTPA with a LocalOS user registry interface. The new configuration is particularly useful for a single node with multiple application servers. It can function in a distributed environment if the local OS user registry implementation is a centralized user registry, such as Windows Domain Controller, or can be maintained in a consistent state on multiple nodes.
WebSphere Application Server supports the J2EE Connector architecture and offers container-managed authentication. It provides a default Java 2 Connector (J2C) principal and credential mapping module that maps any authenticated user credential to a password credential for the specified Enterprise Information Systems (EIS) security domain. The mapping module is a special JAAS login module designed according to the Java 2 Connector and JAAS specifications. Other mapping login modules can be plugged in.
This version maintains backward compatibility with the 5.x release while adding new security functions and moving towards new industry standards. Applications created in the Version 5.x development environment can deploy in V6. When Java 2 Security is enforced in V6, give special consideration to V4.0.x applications because V4.0 applications might not be Java 2 security compliant. Refer to the Security migration section for steps to port a back-level version to V6.
WebSphere Application Server enables you to secure Web services based upon the Organization for the Advancement of Structured Information Standards (OASIS) Web services security Version 1.0 specification. These standards address how to provide protection for messages exchanged in a Web service environment. The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message.
For more information on using trust association, refer to Trust associations.
Security attribute propagation provides propagation services using Java serialization for any objects that are contained in the subject. For more information on using security attribute propagation, refer to Security attribute propagation.
In WebSphere Application Server, the interoperability mode option enables Single Sign-on (SSO) connections between WebSphere Application Server version 5.1.1 or later to interoperate with previous versions of the application server. When you select this option, WebSphere Application Server adds the old-style LtpaToken into the response so that it can be sent to other servers that work only with this token type. This option applies only when the Web inbound security attribute propagation option is enabled. For more information on single sign-on, refer to Implementing single sign-on to minimize Web user authentications.
Each container provides two kinds of security: declarative security and programmatic security. In declarative security, the security structure of an application, including data integrity and confidentiality, authentication requirements, security roles, and access control, is expressed in a form external to the application. In particular the deployment descriptor is the primary vehicle for declarative security in the J2EE platform. WebSphere Application Server maintains a J2EE security policy, including information derived from the deployment descriptor and specified by deployers and administrators in a set of XML descriptor files. At run time, the container uses the security policy defined in the XML descriptor files to enforce data constraints and access control. When declarative security alone is not sufficient to express the security model of an application, the application code can use programmatic security to make access decisions. The API for programmatic security consists of two methods of the Enterprise JavaBeans (EJB) EJBContext interface (isCallerInRole, getCallerPrincipal) and three methods of the servlet HttpServletrequest interface (isUserInRole, getUserPrincipal, getRemoteUser).
Mapping a client certificate to a WebSphere Application Server security credential uses the UserRegistry implementation to perform the mapping.
On WebSphere Application Server Express, the local OS user registry does not support the mapping function.
When the LTPA authentication mechanism is configured and single sign-on (SSO) is enabled, an authenticated client is issued a security cookie, which can represent the user within the specified security domain.
It is recommended that you use Secure Sockets Layer (SSL) to protect the security cookie or Basic Authentication information from being intercepted and replayed. When a trust association is configured, WebSphere Application Server can map an authenticated user identity to security credentials based on the trust relationship established with the secure reverse proxy server.
When considering Web security
collaborators and EJB security collaborators:
When security is enabled, the EJB container enforces access control on EJB method invocation. The authentication takes place regardless of whether a method permission is defined for the specific EJB method.
A Java application client can provide the authentication data in several ways. Using the sas.client.props file, a Java client can specify whether to use a user ID and password to authenticate or to use an SSL client certificate to authenticate. The client certificate is stored in the key file or in the hardware cryptographic card, as defined in a sas.client.props file. The user ID and password can be optionally defined in the sas.client.props file.
At run time, the Java client can either perform a programmatic login or perform a lazy authentication.
In lazy authentication when the Java client is accessing a protected enterprise bean for the first time, the security run time tries to obtain the required authentication data. Depending on the configuration setting in sas.client.props file the security runtime either looks up the authentication data from this file or prompts the user. Alternatively, a Java client can use programmatic login. WebSphere Application Server supports the JAAS programming model and the JAAS login (LoginContext) is the recommended way of programmatic login. The login_helper request_login helper function is deprecated in V5.x and V6. Java clients programmed to the login_helper APT can run in this version.
The EJB security collaborator enforces role-based access control by using an access manager implementation.
An access manager makes authorization decisions based on the security policy derived from the deployment descriptor. An authenticated user principal can access the requested EJB method if it has one of the required security roles. EJB code can use the EJBContext methods isCallerInRole and getCallerPrincipal. EJB code also can use the JAAS programming model to perform JAAS login and WSSubject doAs and doAsPrivileged methods. The code in the doAs and doAsPrivileged PrivilegedAction block executes under the Subject identity. Otherwise, the EJB method executes under either the RunAs identity or the caller identity, depending on the RunAs configuration. The J2EE RunAs specification is at the enterprise bean level. When RunAs identity is specified, it applies to all bean methods. The method level IBM RunAs extension introduced in V4.0 is still supported in this version.
Federal Information Processing Standards (FIPS) are standards and guidelines issued by the National Institute of Standards and Technology (NIST) for federal computer systems. FIPS are developed when there are compelling federal government requirements for standards, such as for security and interoperability, but acceptable industry standards or solutions do not exist.
WebSphere Application Server integrates cryptographic modules including Java Secure Socket Extension (JSSE) and Java Cryptography Extension (JCE), which have undergone FIPS 140-2 certification. Throughout the documentation and the WebSphere Application Server, the IBM JSSE and JCE modules that have undergone FIPS certification are referred to as IBMJSSEFIPS and IBMJCEFIPS, which distinguishes the FIPS modules from the IBM JSSE and IBM JCE modules.
For more information, refer to Configuring Federal Information Processing Standard Java Secure Socket Extension files. The IBMJSSEFIPS module supports the FIPS-approved Transport Layer Security (TLS) cipher suites including:
The IBMJSSEFIPS module supports the following algorithms:
The IBMJCEFIPS module supports the following symmetric cipher suites:
The IBMJCEFIPS module supports the following algorithms:
The IBMJCEFIPS cryptographic module contains the algorithms that
are approved by FIPS, which form a proper subset of those in the IBM JCE modules.