Security is a crucial aspect of your application server environment. IBM® WebSphere® Application Server uses industry standards to secure your applications and resources.
- Resource access control
- Data integrity
- Secure interoperability
- Database 2 (DB2®)
- Information Management System (IMS)
- MQ Series
- Lotus® Domino®
- IBM Directory
- Any System Authorization Facility (SAF)-compliant security server including the IBM z/OS® Security Server Resource Access Control Facility (RACF®)
- Reverse secure proxy server including WebSEAL
For WebSphere Application Server Version 7.x and previous releases:
To take advantage of SAF Security features, users must identify themselves using a z/OS-based user ID. You can use principal mapping modules to map a J2EE identity to your platform-based user ID (in this case a RACF user ID). A principal mapping must be created from the LDAP user ID to the RACF user ID for the SAF EJBROLE checks to be done. This means a mapping login module must be available to derive a z/OS user ID from the configured user in the LDAP registry. (SMF auditing (using SAF) can be used to track these changes.)
New for WebSphere Application Server Version 8.0 and later:
- Use the JAAS mapping module to map the J2EE identity to a SAF identity.
- Use the distributed identity mapping feature in SAF, which requires a certain version of SAF. No JAAS mapping modules should be configured in WebSphere. In this case, users identify themselves using their distributed user identity; for example, the user identity in the LDAP registry. The mapping is handled by the z/OS security administrator using the RACMAP SAF profiles. This option enhances SMF auditing by allowing both the distributed user identity and the SAF identity to be logged in the audit record. Read about Distributed identity mapping using SAF for more information.
Based on industry standards
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 Java EE 6 specification and has passed the J2EE Compatibility Test Suite.
- Java 2 security model, which provides policy-based, fine-grained, and permission-based access control to system resources.
- Common Secure Interoperability Version 2 (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. Important: SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.
- Java Authentication and Authorization Service (JAAS) programming model for Java applications, servlets, and enterprise beans.
- J2EE Connector architecture for plugging in resource adapters that support access to Enterprise Information Systems.
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).
Open architecture paradigm
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 ServerVersion 8.5 and other business application components.
The LTPA authentication mechanism is designed for all platforms 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, Version 6.x or higher 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.
User registries and access control
Information about users and groups reside in a user registry. In WebSphere Application Server, a user registry authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization.
- Local OS (SAF-based)
- Federated repositories
In addition to Local OS, LDAP and federated repository registries, WebSphere Application Server also provides a plug-in to support any registry by using the Custom registry feature (also referred as Custom user registry).
When the Local OS registry implementation of WebSphere Application Server is chosen, it enables you to integrate the functionality of the z/OS Security Server, such as Resource Access Control Facility (RACF), using the Security Access Facility (SAF) in the WebSphere environment directly. If you configure a registry other than Local OS, you can also take advantage of the z/OS Security Server facilities with two options. You can configure a pluggable JAAS mapping module (followed by a WebSphere Application Server for z/OS-supplied JAAS login module) in the appropriate System login configurations. In WebSphere Application Server Version 8.5, you can alternatively use the distributed identity mapping feature.
For more information, refer to Selecting a registry or repository.
WebSphere Application Server configurations: With WebSphere Application ServerVersion 8.5 for z/OS you can integrate existing non-z/OS applications with z/OS-specific facilities such as System Authorization Facility (SAF) and RACF. This allows you to unify registries for WebSphere Application Server for z/OS and non-z/OS platforms. For example:
|Application server configuration||Registry type||Authorization method||Advantage|
|WebSphere Application Server||LDAP||WebSphere bindings and external security providers such as Tivoli® Access Manager||Shared registries (across a heterogeneous platform)|
|WebSphere Application Server for z/OS||RACF||WebSphere bindings and RACF EJBROLEs||Centralized access and auditing ability (can include servers running Version 4.0)|
|WebSphere Application Server mixed environment||LDAP or Custom||WebSphere bindings, external security providers, and RACF EJBROLEs||Shared registries, centralized access, and auditing ability|
- WebSphere Application Server network registry configuration
- WebSphere Application Server for z/OS network registry configuration:
- WebSphere Application Server network registry with z/OS security extensions
- Lightweight Third Party Authentication (LTPA)
Lightweight Third Party Authentication generates a security token for authenticated users, which can be used to represent that authenticated user on subsequent calls to the same or other servers within a single sign-on (SSO) domain.
Security support for Kerberos as the authentication mechanism has been added for this release of WebSphere Application Server. Kerberos is a mature, flexible, open, and very secure network authentication protocol. Kerberos includes authentication, mutual authentication, message integrity and confidentiality and delegation features.
- Simple WebSphere Authentication Mechanism
(SWAM)SWAM is simple to configure and is useful for a single application server environment, but forces a user ID and password authentication for each request.Note: SWAM was deprecated in a previous release of WebSphere Application Server, and will be removed in a future release.
IIOP authentication protocols
IIOP Authentication protocol refers to the mechanisms used to authenticate requests from a Java Client to a WebSphere Application Server for z/OS, or between J2EE Application Servers. Common Secure Interoperability Version 2 (CSIv2) is implemented in WebSphere Application Server for z/OS Version 6.x or later and is considered the strategic protocol.
WebSphere Application Server for z/OS Connector security
WebSphere Application Server 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. z/OS-specific connectors are also supported when the EIS system is in the same security domain as WebSphere Application Server. In this case, passwords are not required, because authenticated credentials used for J2EE requests can be used as EIS credentials.
Web Services Security
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.1 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.
- IBM Tivoli Access Manager for e-business
- Caching Proxy
Security attribute propagation
- An enterprise user registry that queries static attributes
- A custom login module that can query static or dynamic attributes
Single sign-on interoperability mode
In WebSphere Application Server, the interoperability mode option enables Single Sign-on (SSO) connections between WebSphere Application Server version 6.1.x 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
Security for J2EE resources using web containers and EJB containers
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 application programming interface (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).
Java 2 security
WebSphere Application Server supports the Java 2 security model. System codes such as the administrative subsystem, the web container, and the EJB container, are running in the WebSphere Application Server 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. WebSphere Application Server run-time classes are protected by the WebSphere Application Server class loader and are kept invisible to application code.
Java 2 Platform, Enterprise Edition Connector security
WebSphere Application Server 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.
z/OS-specific connectors are also supported when the EIS system is in the same security domain as WebSphere Application Server. In this case, passwords are not required, because authenticated credentials used for J2EE requests can be used as EIS credentials.
For more information refer to Connection thread identity.
All of the application server 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 Server security is enforced, whether Java 2 security is enforced, the authentication mechanism and user registry configuration, security protocol configurations, JAAS login configurations, and Secure Sockets Layer 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 or be mapped to a WebSphere Security domain. 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. WebSphere Security domains allow for more control over the security configuration and can be mapped to individual servers. Read about Multiple security domains for more information.
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 application server level, are managed either by the Web-based administrative console application or by the appropriate scripting application.
- HTTP basic authentication
- HTTPS client authentication
- Form-based Login
- Simple and Protected GSS-API Negotiation (SPNEGO) token
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.
- 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 JSP files can use the HttpServletRequest methods: isUserInRole, getUserPrincipal, and getRemoteUser. As an example, the administrative console uses the isUserInRole method to determine the proper set of administrative functionality to expose to a user principal.
- 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.
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 Version 6.x and Version 8.5. 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 Version 4.0 is still supported in this version.
Federal Information Processing Standards-approved
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.
For more information, refer to Configuring Federal Information Processing Standard Java Secure Socket Extension files.
- AES (FIPS 197)
- TripleDES (FIPS 46-3)
- SHA1 Message Digest algorithm (FIPS 180-1)
- Digital Signature DSA and RSA algorithms (FIPS 186-2)
- ANSI X 9.31 (FIPS 186-2)
- IBM Random Number Generator
The IBMJCEFIPS cryptographic module contains the algorithms that are approved by FIPS, which form a proper subset of those in the IBM JCE modules.