WebSphere Application Server Version 6.1 Feature Pack for Web Services
             Operating Systems: z/OS

             Personalize the table of contents and search results
This topic applies only on the z/OS operating system.

Security considerations for WebSphere Application Server for z/OS

Functions supported on WebSphere Application Server for z/OS

WebSphere Application Server for z/OS supports the following functions.

Table 1. Functions supported on WebSphere Application Server for z/OS
Function Additional information
RunAs EJB For more information, see Delegations.
RunAs for Servlets For more information, see Delegations.
System Authorization Facility (SAF)-based IIOP Protocols For more information, see Common Secure Interoperability Version 2 and Secure Authentication Service client configuration.
z/OS connector facilities For more information, see Resource Recovery Services (RRS).
Administrative security For more information, see Administrative security.
Application security For more information, see Application security.
Java 2 security For more information, see Java 2 security.
Disable security For more information, see Disabling administrative security.
SAF keyrings For more information, see Using System Authorization Facility keyrings with Java Secure Sockets Extension.
Authentication functions Authentication function examples: Basic, SSL digital certificates, form-based login, security constraints, trust association interceptor
J2EE security resources For more information, see Task overview: Securing resources.
Web authentication (LTPA) For more information, see Configuring the Lightweight Third Party Authentication mechanism.
IIOP using LTPA For more information, see Lightweight Third Party Authentication.
WebSphere application bindings WebSphere application bindings can be used to provide user to role mappings.
Synch to OS Thread For more information, see Java thread identity and an operating system thread identity.
J2EE role-based naming security For more information, see Java 2 Platform, Enterprise Edition (J2EE) specification.
J2EE role-based administrative security For more information, see Java 2 Platform, Enterprise Edition (J2EE) specification.
SAF registries For more information, see User registries and repositories.
Identity assertion

For more information, see .

Authentication protocols Example: z/SAS, CSIV2

For more information, see Authentication protocol support.

CSIv2 conformance level "0" For more information, see Security planning overview.
J2EE 1.4 compliance For more information, see Java 2 Platform, Enterprise Edition (J2EE) specification.
JAAS programming model WebSphere extensions For more information, see Using the Java Authentication and Authorization Service programming model for Web authentication.
All basic WebSphere Application Servers provide the following functions:
  • Using RunAs: Use RunAs to change the identity of a caller, server, or role. This designation is now part of the servlet specification.
  • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Support of SAF-based IIOP authentication protocols: Network Deployment uses Secure Authentication Services (SAS) for Internet Inter-ORB Protocol (IIOP) authentication. z/OS has its own version of SAS called z/OS Secure Authentication Services (z/SAS) (with similar functions but different mechanisms), and it handles functions such as local security, Secure Sockets Layer (SSL)-based authorization, digital certificates with System Authorization Facility (SAF) mapping, and SAF identity assertion.
    Important: z/SAS is supported only between Version 6.0.x and previous version servers that have been federated in a Version 6.1 cell.
  • SAF-based authorization and RunAs capability: Use SAF (EJBROLE) profiles for permission and delegation security information.
  • Support for z/OS connector facilities: Instead of using an alias where a user ID and password is stored, the ability to propagate local OS identities is supported.
  • SAF keyring support for HTTP and IIOP: Use SystemSSL for HTTP, IIOP, and SAF key ring support. You can also use JSSE.
  • Authentication functions: Web Authentication mechanisms such as basic, SSL digital certificates, form-based login, security constraints, and trust association interceptor offer the same functionality in Version 6.1 as offered in Version 5.
  • Authorization for J2EE resources: Authorization for Java 2 Platform, Enterprise Edition (J2EE) resources employs roles similar to the ones used in Version 4, and these roles are used as descriptors.
  • Security enablement: Security can be enabled or disabled globally. When the server comes up there is some level of security on, but security is disabled until the administrator sets it up.
  • Web authentication using LTPA and SWAM: Single sign-on (SSO) using Lightweight Third Party Authentication (LTPA) or Simple WebSphere Authentication Mechanism (SWAM) is supported.
    [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] Note: SWAM is deprecated in WebSphere Application Server Version 6.1 and will be removed in a future release.
  • IIOP authentication using LTPA: IIOP authentication using LTPA is supported.
  • WebSphere Application Bindings for Authorization: WebSphere Application Bindings for Authorization are now supported.
  • Synch to OS Thread: Application Synch to OS Thread is supported.
  • J2EE role-based naming security: J2EE roles are used to protect access to the namespace. The new roles and tasks are cosNamingRead, cosNamingWrite, cosNamingCreate, and cosNamingDelete.
  • Role-based administrative security: The roles delimiting security are:
    • Monitor (least authorization and is read-only)
    • Operator (can do runtime changes)
    • Configurator (can monitor and configuration privileges)
    • Administrator (most authorization)
    • Deployer (used by wsadmin for configuration actions and runtime operations on applications)
    • Adminsecuritymanager (can map users to administrative roles and manage authorization groups)

    For more information on administrative roles, see Administrative roles.

Comparing WebSphere Application Server for z/OS with other WebSphere Application Server platforms

A key similarity:
  • Pluggable security model: The pluggable security model can be authenticated in IIOP Common Secure Interoperability Version 2 (CSIv2), Web Trust Authentication, Java Management Extensions (JMX) Connectors, or the Java Authentication and Authorization Service (JAAS) programming model. You must:
    1. Determine which registry is appropriate and what authentication (token) mechanisms are needed
    2. Determine whether or not the registry is local or remote, and what Web authorizations should be used - Web authorizations include Simple WebSphere authentication mechanism (SWAM) and Lightweight Third-Party Authentication (LTPA)
      Note: SWAM is deprecated in WebSphere Application Server Version 6.1 and will be removed in a future release.
Key differences include:
  • SAF registries: Local operating system registries provide premium functionality on z/OS because z/OS spans a sysplex rather than a single server. z/OS provides certificate to user mapping, authorization, and delegation functions.
  • Identity assertion: Use trusted servers or CBIND to get the authorization required for the server doing the assertion. Distributed platform requires a server to be placed in the trusted server list. z/OS requires a server ID to have a specific CBIND authorization. The Assertion types are SAF user ID, Distinguished Name (DN), and SSL client certificate.
  • [This information applies to Version 6.0.x and previous servers only that are federated in a Version 6.1 cell.] zSAS and SAS authentication protocols for IIOP clients: z/SAS differs from SAS because it supports RACF PassTickets. The SAS layer in WebSphere Distributed uses Common Object Request Broker Architecture (CORBA) portable interceptors to implement their Secure Association Service, and z/OS does not.
  • CORBA features: z/OS does not support CORBA security interfaces including the CORBA current, LoginHelper, Credentials, and ServerSideAuthenticator models. CORBA functions have been migrated to JAAS.

    The LoginHelp application programming interface (API) is deprecated in WebSphere Application Server Version 6.1. For more information, see Migrating Common Object Request Broker Architecture programmatic login to Java Authentication and Authorization Service (CORBA and JAAS).

  • Authentication protocols: CSIv2 is an Object Management Group (OMG) specification for the z/OS Security Server and is automatically enabled when WebSphere security is enabled. This is a three-layered approach involving secure sockets layer transport layer security (SSL/TLS) for message protection, supplemental client authentication layer for user ID and password Generic Security Services Username Password (GSSUP), and security attribute layer used by middle servers (who must be specially authorized to the target server ) for identity assertion.

J2EE 1.3 compliance

Being J2EE-compliant involves:
  • CSIv2 conformance level "0": This is an Object Management Group (OMG) (related to the z/OS Security Server) specification, which is part of what used to be CORBA support. CSIv2 is automatically enabled when security is enabled.
  • Use of Java 2 security: There is "security-enabled" and "Java 2 security-enabled", and the default for Java2 is "on". This provides a fine-grained access control that is code-based as opposed to subject-based authorization. Each class belongs to one particular domain. Permissions protected by Java 2 security include file access, network access, sockets, exiting Java virtual machine (JVM), administration of properties, and threads. The security manager is what Java 2 uses as a mechanism for managing security and enforcing the required protections. Extensions to Java 2 security include use of dynamic policy (permissions resource type-based rather than code-based), use of specific default permissions defined for resources in template profiles, and use of filter files to disable policy.
  • Use of JAAS programming: JAAS programming includes a standard set of APIs for authentication. JAAS is the strategic authorization and authentication mechanism. IBM Developer Kit for Java Technology Edition Version 5 is shipped with WebSphere Version 6.1, but some extensions are supplied.
  • Use of the servlet RunAs function: WebSphere Application Server on the distributed platforms (not the z/OS platform) refers to this function as Delegation Policy. You can change identity to run as a system, caller, or role (user). This function is now part of the servlet specification. Authentication involves using a user ID and password and then mapping the alias to the appropriate XML file or EJBROLE to find the user ID of the RunAs role.

Compliance with WebSphere Application Server Network Deployment at the API/SPI level

Compliance with WebSphere Application Server Network Deployment at the application programming interface or Service Provider Programming Interface (API/SPI) level makes it easier to deploy applications from Network Deployment on z/OS. Features enhanced or deprecated by Network Deployment are enhanced or deprecated by z/OS. However, this does not mean there is no migration for z/OS customers. Compliance with WebSphere Network Deployment at the API/SPI level includes:
  • WebSphere Application Server extensions to the JAAS programming model: The authorization model is an extension of the Java 2 security model for JAAS programming (so it works with the J2EE model). Subject-based authorization is performed on authenticated user IDs. Instead of merely logging in with a user ID and password, there is now a login process that includes creating a login context, passing callback handlers that prompt for user ID and password, and logging in. WebSphere Application Server for z/OS supplies the login module, the callback handler to retrieve the necessary data, the callbacks, the WSSubject choice, getCallerSubject, and getRunAsSubject.
  • Use of the WebSphere Application Server security APIs: z/OS supports WebSphere Application Server security APIs.
  • Use of secure JMX connectors: JMX connectors can be used with user ID and password credentials. The two connector types are RMI and SOAP/HTTPS (and are for administration). The SOAP connector uses the JSSE SSL repertoires. The RMI connector is subject to the same advantages and restrictions as IIOP mechanisms (such as CSIv2).



Related tasks
Task overview: Securing resources
Concept topic    

Terms of Use | Feedback

Last updated: Nov 25, 2008 2:35:59 AM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/csec_oversecure.html