Note: If you would prefer to browse PDF versions of this documentation
using your Adobe Reader
, see the Security PDF files available
from www.ibm.com/software/webservers/appserv/infocenter.html
.
Overview
IBM WebSphere Application Server for z/OS provides security infrastructure and mechanisms to protect sensitive Java 2 Platform, Enterprise Edition (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 WebSphere Application Server for z/OS security is based on industry standards. There is an open architecture that processes secure connectivity and interoperability with Enterprise Information Systems including:
WebSphere Application Server also supports other security providers including:
Based on industry standards
The product provides a unified, policy-based, and permission-based model for securing Web resources and enterprise JavaBeans according to J2EE specifications. Specifically Version 5 complies with J2EE specification Version 1.3 and has passed the J2EE Compatibility Test Suite. Product 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:
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 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 light blue shaded background indicates the boundary between the product and other business application components.
Key concepts
In WebSphere Application Server for z/OS Version 5, security services are configured at a cell level. The configurable services include a Web authentication mechanism, a user registry, and an access control manager. In Version 5, 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):
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. The
Local OS registry implementation of WebSphere Application Server for z/OS
integrates the functionality of the z/OS Security Server, such as RACF, using
the Security Access Facility (SAF) in the WebSphere environment. When Local
OS is configured, the SAF authorization may be chosen to provide J2EE access
control.
Alternatively an LDAP
(Lightweight Directory Access Protocol) registry may be configured contain
user and group information.
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). See User registries.
The
product provides the following user registry implementations:
Note: LDAP
and Custom Registry identities are scoped to a single Web application, which
includes co-located EJBs (that is, EJBs in the same Web Application processed
on the same server). Local OS identities are the only ones currently propagated
to EJBs.
WebSphere Application Server provides the following user registry implementations:
Application server configuration | Registry type | Authorization method | Advantage |
---|---|---|---|
WebSphere Application Server | LDAP | WebSphere bindings and external security providers such as Tivoli Access Manager (TAM) | 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 (not TAM), and RACF EJBROLEs | Shared registries, centralized access, and auditing ability |
Web authentication mechanisms
In WebSphere Application Server for z/OS Version 5, three Web authentication mechanisms are supported:
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.
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.
ICSF can be configured as an alternative to LTPA on the z/OS platform to generate a security token for authenticated users. It takes advantage of a cryptographic programming interface to the secure hardware cryptographic features of the zSeries processors. The keys are stored in secure hardware using ICSF and only the key label is externalized. ICSF is a cryptographic programming interface to the secure hardware cryptographic features of the zSeries processors. ICSF also generates security tokens for authenticated users which can be propagated over to other servers. The main advantage of ICSF is that the keys are stored in secure hardware and only the key label is provided. However, if you need to interoperate with network distributed servers you must use LTPA.
LTPA authentication tokens are propagated using Single Sign On (SSO). These tokens are not used for authentication when enterprise beans are invoked on other servers.
Note: ICSF will be deprecated starting with WebSphere
Application Server for z/OS Version 6.
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. There are two sets authentication protocols supported by WebSphere Application Server for z/OS Version 5. z/OS Secure Association Service (z/SAS) is the set of authentication protocols used by all previous releases of the WebSphere product, 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 and is considered the strategic protocol.
WebSphere Application Server for z/OS Connector security
The product 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
While adding new security functions and moving towards new industry standards, this version maintains backward compatibility with the 4.0.x and 3.5.x releases. Applications created in the Version 4.x development environment can deploy in Version 5. When Java 2 Security is enforced in Version 5, 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 Version 4.0.x to Version 5. See also the Security section of New in this release.
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. In particular the deployment descriptor is the primary vehicle for declarative security in the J2EE platform. The product 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 two methods of the servlet HttpServletrequest interface (isUserInRole, getUserPrincipal).
Securing resources in WebSphere Application Server for z/OS Version 5
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 Administrative Service interface through JMX connectors, the user registry interface, and the naming interface are protected by extended security role-based access control.
Java 2 security: The product supports the Java 2 security model. All the system code, including the administrative subsystem, the Web container, and the EJB container code, are running in the product 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 with permissions according to J2EE specifications, only can access a restricted set of system resources. The product run-time classes are protected by the product class loader and are kept invisible to application code.
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 product 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, 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 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, ensure the data constraints are met, and determine whether the authenticated user has the required security role. The product supports the following login methods: HTTP basic authentication, Hypertext Transfer Protocol with Secure Sockets Layer (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 .
When the LTPA or ICSF authentication mechanism is configured and single signon (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 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.