Security


 

+

Search Tips   |   Advanced Search

 

IBM WAS provides security infrastructure and mechanisms to protect sensitive J2EE resources and admin resources. It also addresses enterprise end-to-end security requirements on:

IBM WAS security is based on industry standards and has an open architecture that ensures secure connectivity and interoperability with EIS including:

WAS also supports other security providers including:

 

Based on industry standards

IBM WAS provides a unified, policy-based, and permission-based model for securing Web resources, Web service endpoints, and enterprise Java Beansaccording to J2EE specifications. Specifically, WAS complies with J2EE spec V1.4 and has passed the J2EE Compatibility Test Suite. WebSphere Application WAS 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 models and interfaces that support secure socket communication, message encryption, and data encryption are the JSSE (JSSE) and the JCE.

 

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 dark blue shaded background indicates the boundary between the WAS V7.0 and other business application components. WAS provides SWAM, LTPA, and Kerberos as the authentication mechanism. Exactly one authentication mechanism can be configured to be the active authentication mechanism for the security domain of WAS.

Exactly one user registry implementation can be configured to be the active user registry of WAS security domain. WebSphereApplication Server provides the following user registry implementations...

It also provides file-based and 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 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 appservers.

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.

SWAM was deprecated in WAS V7.0 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, which is discussed later. Besides the combination of LTPA and LDAP or Custom user registry interface, V6.x or higher 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 J2C and JAAS specifications. Other mapping login modules can be plugged in.

 

WS-Security

WAS enables you to secure Web services based upon the OASIS WS-Security V1.1 specification. These standards address how to provide protection for messages exchanged in a Web service environment. The spec defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message.

 

Trust associations

Trust association enables you to integrate IBM WAS security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the WAS applies its own authorization policy onto the resulting credentials that are passed by the proxy server. The reverse proxy server applies its authentication policies to every Web request that is dispatched to WAS. The products that implement trust association interceptors (TAI) include:

 

Security attribute propagation

Security attribute propagation enables WAS to transport security attributes from one server to another in the configuration. Security attributes include authenticated subject contents and security context information. WAS can obtain these security attributes from either:

Security attribute propagation provides propagation services using Java serialization for any objects that are contained in the subject.

See on using security attribute propagation, refer to Security attribute propagation.

 

Single sign-on interoperability mode

In WAS, the interoperability mode option enables Single Sign-on (SSO) connections between WAS version 5.1.1 or later to interoperate with previous versions of the appserver. When you select this option, WAS 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.

See on single sign-on, refer to Implementing single sign-on to minimize Web user authentications

 

Security for J2EE resources using Web containers and EJB containers

Each container provides two kinds of 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. WAS 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 EJBs EJBContext interface...

...and three methods of the servlet HttpServletrequest interface...

 

Java 2 security

WAS supports the Java 2 security model. All the system codes in the yellow box, including the admin subsystem, the Web container, and the EJB container code, are running in the WAS security domain, which in the present implementation are granted with AllPermission and can access all system resources. Application code running in the application security domain, which by default is granted with permissions according to J2EE specifications, can access only a restricted set of system resources. WAS run-time classes are protected by the WAS class loader and are kept invisible to application code.

 

Java 2 Platform, Enterprise Edition Connector security

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 EIS security domain.

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 WebSphere Application WAS 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 appserver process can create a per server security configuration to address its own security requirement. Not all security configurations can be modified at the appserver level. Some security configurations that can be modified at appserver level include whether application security should be enforced, whether Java 2 security should be enforced, and security protocol configurations.

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 admin console application or by the appropriate scripting application.

 

Web security

When a security policy is specified for a Web resource and IBM WebSphere Application 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, ensures that the data constraints are met, and determines whether the authenticated user has the required security role. WAS supports the following login methods:

Mapping a client certificate to a WebSphere Application WAS security credential uses the UserRegistry implementation to perform the mapping.

On WAS Express, the local OS user registry does not support the mapping function.

When the LTPA authentication mechanism is configured and 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 SSL to protect the security cookie or Basic Authentication information from being intercepted and replayed. When a trust association is configured, WAS 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:

  1. 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 the user principal has one of the required security roles. Servlets and JSPs can use the HttpServletRequest methods: isUserInRole, getUserPrincipal, and getRemoteUser.

    As an example, the admin console uses the isUserInRole method to determine the proper set of admin functionality to expose to a user principal.

  2. 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 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.

 

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 sas.client.props, 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 sas.client.props.

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 model and the JAAS login (LoginContext) is the recommended way of programmatic login. The login_helper request_login helper function is deprecated in V6.x and V 7.0. 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 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 spec 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.

 

FIPSs-approved

FIPSs (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 JSSE (JSSE) and JCE, which have undergone FIPS 140-2 certification. Throughout the documentation and the WAS, 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 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.



Related concepts

Access control exception
CSIv2 features
Delegations
Administrative security
Server and admin security
Java Authentication and Authorization Service
J2EE connector security
Standalone LDAP registries
Local operating system registries
Lightweight Third Party Authentication
Programmatic login for JAAS
Role-based authorization
Java 2 security
Trust associations

 

Related tasks

Select an authentication mechanism
Select a registry or repository
Set FIPS JSSE files
Secure Web services applications using message level security
Secure Web services for V5.x applications based on WS-Security

 

Related

Java 2 security policy files

 

Related information

Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List