Security

The following information provides an overview of security in WebSphere Application Server.

IBM WebSphere Application Server provides security infrastructure and mechanisms to protect sensitive Java 2 Platform, Enterprise Edition (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:

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 J2EE specification Version 1.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 Java virtual machine (JVM), and Java 2 security. This security model employs a rich set of security technology including the:
  • Java 2 security model, which provides policy-based, fine-grained, and permission-based access control to system resources.
  • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] 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 Server Version 6 and other business application components.

Integrating WebSphere Application Server for z/OS

Using the z/OS platform with SAF offers facilities to simplify the following tasks:
  • Securing and isolating data
  • Network access
  • Accessing existing Enterprise subsystems
WebSphere Application Server for z/OS:
  • Incorporates these essential features of z/OS security
  • Enables you to deploy Web-based applications on z/OS

Key concepts

In WebSphere Application Server for z/OS Version 6, security services are configured at a cell level. The configurable services include a web authentication mechanism, a user registry, and an access control manager. Unless otherwise specified, the access control facility is provided by WebSphere bindings.

WebSphere Application Server for z/OS security has some basic concepts to familiarize yourself with, including (but not limited to):

WebSphere Application Server for z/OS-specific security: WebSphere Application Server for z/OS provides the same functions that non-z/OS platforms provide with some additional optional features. In WebSphere Application Server for z/OS, security services are configured at a cell level. The configurable services include a Web authentication mechanism, a user registry, and an authorization facility. Authorization facility is provided by WebSphere bindings.

Unlike other platforms, WebSphere Application Server for z/OS offers security facilities (extensions) that require permission to protected resources and files because z/OS is secure by default. While it can be configured similarly to other WebSphere Application Server platforms, WebSphere Application Server for z/OS Version 6 provides support for configuring the active WebSphere Application Server user registry as LDAP or a Custom registry while also taking advantage of RACF and SAF services such as the ones pointed out in System Authorization Facility security. For more information, refer to WebSphere Application Server configurations information in this article.

When you install, configure, or customize WebSphere Application Server for z/OS security in a z/OS environment, many of the activities are automated and can be performed using the WebSphere Application Server for z/OS customization dialog. You must permit WebSphere Application Server to use the applicable z/OS capabilities, including the profiles used to enforce system-level security (using the RACF STARTED class or RACF-started-procedures table).
Note: For z/OS you can also configure WebSphere Application Server to use any SAF-compliant security server, such as RACF, to control authorization for the Application Server.
The default setup for WebSphere Application Server for z/OS using RACF is provided through REXX executables to assist in installing and setting up the security installation. These executables include:
  • BBOSBRAC
  • BBOCBRAC
  • BBODBRAC
These REXX executables:
  • Generate and issue the RACF commands necessary to define users, groups, profiles, and permissions for the WebSphere Application Server for z/OS run-time and LDAP
  • Define digital certificates that are stored in a RACF keyring
These executables affect the following RACF classes:
  • FACILITY
  • LOGSTRM
  • SERVER
  • STARTED
  • CBIND
  • SURROGAT
  • APPL

For more information on RACF profiles and RACF classes, refer to the z/OS Security Server RACF System Adminstrator's Guide.

System Authorization Facility (SAF) security: WebSphere Application Server for z/OS can optionally interact and integrate with your selected platform security. With WebSphere Application Server for z/OS Version 5.x or Version 6 you can take advantage of:
  1. WebSphere Application Server for z/OS authorization using SAF EJBROLES profiles. Refer to System Authorization Facility for role-based authorization for more information.
  2. SAF-based identity management, involving using the J2EE client identity as the identity when issuing Java-based connectors to other EIS systems such as Customer Information Control System (CICS), Information Management Systems (IMS), Database 2 (DB2) or MQSeries. Refer to Enabling pluggable login modules to map J2EE identities to System Authorization Facility (SAF) for more information.
  3. SAF identity management, including enabling an application to run a WebSphere Application Server for z/OS application and set the operating system (OS) identity to match the J2EE identity, which is known as application Synch to OS Thread. Refer to Application Synch to OS Thread Allowed for more information.
  4. SAF auditing to use audit records (stored in Systems Management Facility (SMF)) generated by the authorization checks to track changes and access attempts. For more information, refer to:

Identification management: 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 in order 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.)

For more information, refer to Custom System Authorization Facility mapping modules and Installing and configuring a custom System Authorization Facility mapping module for WebSphere Application Server.

If you want to relate J2EE identities to the existing WebSphere Application Server for z/OS security infrastructure, you can synchronize the OS thread of execution and additionally map J2EE to z/OS identities.
Note: If you choose a local OS user registry or if you want to use the current identity as the thread identity, you can use a mapping module to select which z/OS user identity is put on the thread of execution.
This mapping between J2EE and z/OS is essential for easing security administration when using WebSphere Application Server for z/OS. The WebSphere Application Server for z/OS user is identified using a principal that is authenticated by WebSphere Application Server in order to access a WebSphere Application Server resource in a secure environment. The WebSphere Application Server authenticates the user identity and represents the user with a Java Authentication and Authorization Service (JAAS) subject. For more general information on this identification management, refer to:

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.

WebSphere Application Server provides the following user registry implementations:
  • Local OS (SAF-based)
  • LDAP

In addition to Local OS and LDAP 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 your active LDAP or Custom user registry you can also take advantage of these z/OS Security Server facilities by configuring a custom or IBM-supplied pluggable mapping module (followed by a WebSphere Application Server for z/OS-supplied module) in the appropriate System Login configurations.

If a registry other than Local OS is selected and no mapping is done (or no valid mapping is available for a particular identity), these facilities are unavailable.

The LDAP UserRegistry supports the mapping function.

For more information, refer to User registries and repositories.

WebSphere Application Server configurations: With WebSphere Application Server for z/OS Version 6 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
Here are some pictures to show what is described in the table above.
  • 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

Authentication mechanisms

In WebSphere Application Server for z/OS, two authentication mechanisms are supported:
  • 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 is deprecated in WebSphere Application Server Version 6.1 and will be removed in a future release.
  • 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. If you need to interoperate with network distributed servers you must use LTPA.

IIOP authentication protocols

[This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] 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. There are two sets authentication protocols supported by WebSphere Application Server for z/OS Version 5.x or Version 6. z/OS Secure Association Service (z/SAS) is the set of authentication protocols used by all previous releases of WebSphere Application Server, such as user ID and PassTicket, SSL Basic Authentication, and Kerberos. Common Secure Interoperability Version 2 (CSIv2) is implemented in WebSphere Application Server for z/OS Version 5.x or Version 6 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.

Backward compatibility

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 Version 6. When Java 2 Security is enforced in Version 6, give special consideration to Version 4.0.x applications because Version 4.0 applications might not be Java 2 security compliant. Refer to the Security migration section for steps to port a back-level version to Version 6.

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

Trust associations

Trust association enables you to integrate IBM WebSphere Application Server security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the WebSphere Application Server 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 WebSphere Application Server. The products that implement trust association interceptors (TAI) include:
  • IBM Tivoli Access Manager for e-business
  • WebSEAL
  • Caching Proxy
For more information on using trust association, refer to Trust associations.

Security attribute propagation

Security attribute propagation enables WebSphere Application Server to transport security attributes from one server to another in your configuration. Security attributes include authenticated subject contents and security context information. WebSphere Application Server can obtain these security attributes from either:
  • An enterprise user registry that queries static attributes
  • A custom login module that can query static or dynamic attributes
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.

Security attribute propagation allows communication from a WebSphere Application Server, WebSphere Application Server Network Deployment, or WebSphere Application Server Express LDAP user registry to a WebSphere Application Server for z/OS SAF user registry.

Single sign-on interoperability mode

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.

Securing resources in WebSphere Application Server for z/OS Version 6

From a security perspective, every application server 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 Admin Service interface through Java Management Extensions (JMX) connectors, the user registry interface, and the naming interface are protected by extended security role-based access control. All the system code, including the administrative subsystem, the Web container, and the EJB container code, are running in the WebSphere Application Server security domain. The system code, shown in the WebSphere Application Server security domain box in the following diagram, is granted AllPermission and can access all system resources. Application code running in the application security domain, which by default is granted permissions according to J2EE specifications, only can access a restricted set of system resources. WebSphere Application Server Version 6 run-time classes are protected by WebSphere Application Server class loader and are kept invisible to application code.

Security for J2EE resources is provided by 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. The deployment descriptor is the primary vehicle for declarative security in the J2EE platform. WebSphere Application Server Version 6 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 EJB EJBContext interface (isCallerInRole, getCallerPrincipal) and the three methods of the servlet HttpServletrequest interface (isUserInRole, getUserPrincipal, getRemoteUser).

Java 2 security

WebSphere Application Server supports the Java 2 security model. All the system codes in the yellow box, including the administrative subsystem, the Web container, and the EJB container code, 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. 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 application server level, is managed either by the Web-based administrative console application or by the appropriate scripting application.

Note: You cannot change user registry and authentication mechanisms at the server level.

Web security

When a security policy is specified for a Web resource and IBM WebSphere Application Server 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. WebSphere Application Server supports the following login methods:
  • HTTP basic authentication
  • HTTPS client authentication
  • Form-based Login
Mapping a client certificate to a WebSphere Application Server security credential uses the UserRegistry implementation to perform the mapping.

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

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.

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.

Note: After authorization is done, the RunAs identity is used downstream. This is typically the caller's identity but it can also be a delegated identity.

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.

[Updated in July 2012] WebSphere Application Server integrates cryptographic modules including Java Secure Socket Extension (JSSE) and Java Cryptography Extension (JCE), which have undergone FIPS 140-2 certification. [Updated in July 2012]

jul2012

The IBMJCEFIPS module supports the following symmetric cipher suites:
  • AES (FIPS 197)
  • TripleDES (FIPS 46-3)
  • SHA1 Message Digest algorithm (FIPS 180-1)
The IBMJCEFIPS module supports the following algorithms:
  • 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.




Related concepts
Access control exception
Authentication mechanisms
Common Secure Interoperability Version 2 features
Delegations
Server and administrative security
Java Authentication and Authorization Service
J2EE connector security
Standalone Lightweight Directory Access Protocol registries
Local operating system registries
Lightweight Third Party Authentication
User registries and repositories
Role-based authorization
Java 2 security
Trust associations
Related tasks
Securing Web services applications using JAX-RPC at the message level
Securing Web services for Version 5.x applications based on WS-Security
Related reference
Java 2 security policy files
Related information
Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=welc_security
File name: welc_security.html