Welcome to Security

 

Overview

IBM WAS V5 provides security infrastructure and mechanisms to protect sensitive J2EE resources and administrative resources and to address enterprise end-to-end security requirements on authentication, resource access control, data integrity, confidentiality, privacy, and secure interoperability. IBM WAS security is based on industry standards. V5 has an open architecture that processes secure connectivity and interoperability with Enterprise Information Systems including:

WAS also supports other security providers including:

 

Based on industry standards

WAS provides a unified, policy-based, and permission-based model for securing Web resources and enterprise JavaBeans according to J2EE specifications. Specifically V5 complies with J2EE specification V1.3 and has passed the J2EE Compatibility Test Suite. Product 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:

The standard security model and interface supported include Java Secure Socket Extension (JSSE) and Java Cryptographic Extension (JCE) provider for secure socket communication, message encryption, and data encryption.

 

Open architecture paradigm

An appserver plays an integral part in the multiple-tier enterprise computing framework. IBM WAS 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 light blue shaded background indicates the boundary between the product and other business application components.

WAS provides SWAM and LTPA mechanisms. Exactly one may be configured to be the active authentication mechanism for the security domain of the product. Exactly one user registry implementation may be configured to be the active user registry of the product security domain.

SWAM is simple to configure and is useful for a single appserver 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. Note that identity assertion feature is available only on the CSIv2 security protocol.

WAS provides the following user registry implementations:

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 signon, which will be discussed later. Besides the combination of LTPA and LDAP or Custom user registry interface, V5 supports LTPA with a LocalOS user registry interface. The new configuration is particularly useful for a single node with multiple appservers. 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.

WAS supports the J2EE Connector architecture and offers container-managed authentication. It provides a default 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.

Note that WAS V5.1 does not support Windows NT.

 

Web containers and EJB containers

XML deployment descriptors are the primary enabler of run time declarative security in the J2EE platform, handling....

If declarative security alone is insufficient, application code can use to make access decisions. The API consists of EJBContext (isCallerInRole, getCallerPrincipal) and HttpServletrequest (isUserInRole, getUserPrincipal).

From a security perspective, every appserver process consists of a Web container, an EJB container, and the administrative subsystem. There are many other components that constitute a server process, which are not discussed here. Remote interfaces to the administrative subsystem, including the Administrative Service interface through JMX connectors, the user registry interface, and the naming interface are protected by extended security role-based access control.

WAS supports the Java 2 security model where the system code, including the administrative subsystem, the Web container, and the EJB container code, run in the product security domain.

System code is granted AllPermission and can access all system resources. Application code runs in the application security domain can only access a restricted set of system resources. WAS run-time classes are protected by class loader and are kept invisible to application code.

Security services consist of an authentication mechanism, a user registry, and an access control manager. All of the appserver processes, by default, share a common security configuration, which is defined in a cell-level security XML document. The security configuration determines whether product security is enforced, whether Java 2 security is enforced, the authentication mechanism and user registry configuration, security protocol configurations, JAAS login configurations, and SSL configurations. Applications can have their own unique security requirements. Each application server process can create a per server security configuration to address its own security requirement. Not all security configurations can be modified at the application server level. Some security configurations that can be modified at application server level include whether application security should be enforced, whether Java 2 security should be enforced, and security protocol configurations. For more general information refer to Security states with thread identity support.

The administrative subsystem security configuration is always determined by the cell level security document. The Web container and EJB container security configuration are determined by the optional per server level security document, which has precedence over the cell-level security document.

Security configuration, both at the cell level and at the appserver level, are managed either by the Web-based administrative console application or by the WSADMIN scripting application.

 

Web security

When a security policy is specified for a Web resource and IBM WAS security is enforced, the Web container performs access control when the resource is requested by a Web client. The Web container challenges the Web client for authentication data if none is present according to the specified authentication method, ensure the data constraints are met, and determine whether the authenticated user has the required security role. WAS supports the following login methods: HTTP basic authentication, Hypertext Transfer Protocol with SSL (HTTPS) client authentication, and form-based Login. Mapping a client certificate to a product security credential uses the UserRegistry implementation to perform the mapping. The LDAP UserRegistry supports the mapping function while LocalOS UserRegistry does not.

When the LTPA authentication mechanism is configured and single signon 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 SSL to protect the security cookie from being intercepted and replayed. When a trust association is configured, the product can map an authenticated user identity to security credentials based on the trust relationship established with the secure reverse proxy server.

The Web 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 Servlet or JSP file if it has one of the required security roles. Servlets and JSP files can use the HttpServletRequest methods: isUserInRole and getUserPrincipal. As an example, the administrative console uses the isUserInRole method to determine the proper set of administrative functionality to expose to a user principal.

 

EJB security

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. WAS 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. 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-approved

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.

WAS 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 product, 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.

The IBMJSSEFIPS module supports the FIPS-approved 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 IBMJSSEFIPS and IBMJCEFIPS cryptographic modules only contain the algorithms that are approved by FIPS, which form a proper subset of those in the IBM JSSE and IBM JCE modules.

Related concepts
AccessControlException
Authentication mechanisms
Authentication protocol for EJB security
Common Secure Interoperability V2 features
Delegations
Enterprise bean component security
Global security and server security
Java Authentication and Authorization Service
Java 2 Connector security
Lightweight Directory Access Protocol
Local operating system user registries
Lightweight Third Party Authentication
Programmatic login
User registries
Role-based authorization
Java 2 security policy files
Trust Associations
Related tasks
Configuring Federal Information Processing Standard Java Secure Socket Extension files
Related reference
Java 2 security
Related topics
Cryptographic Module Validation Program FIPS 140-1