(zos)

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.

Function	Additional information
RunAs EJB	For more information, see Delegations.
RunAs for Servlets	For more information, see Delegations.
SAF-based IIOP Protocols	For more information, see CSIv2 and Security Authentication Service (SAS) 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 Disable administrative security.
SAF keyrings	For more information, see Use 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 Configure the Lightweight Third Party Authentication mechanism.
IIOP using LTPA	For more information, see LTPA>.
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.
SAF registries	For more information, see Select a registry or repository.
Identity assertion	For more information, see Identity assertion.
Authentication protocols	Example: z/SAS, CSIV2 For more information, see Authentication protocol support.
CSIv2 conformance level "0"	For more information, see Security planning overview.
JAAS programming model WebSphere extensions	For more information, see Use the Java Authentication and Authorization Service programming model for web authentication.
Distributed identity mapping using SAF	For more information, see Distributed identity mapping using SAF

All basic WebSphere Application Servers provide the following functions:

• Use RunAs: Use RunAs to change the identity of a caller, server, or role. This designation is now part of the servlet specification.

• Support of SAF-based IIOP authentication protocols: WebSphere Application Server Network Deployment uses Secure Authentication Service (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, 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. We 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 v8.5 as offered in Version 5.

• Authorization for J2EE resources: Authorization for 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 LTPA or SWAM is supported.

  SWAM is deprecated in WebSphere Application Server v8.5 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 CSIv2 (CSIv2), Web Trust Authentication, JMX Connectors, or the JAAS programming model. We 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 LTPA

     SWAM is deprecated in WebSphere Application Server v8.5 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.

• 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 (API) is deprecated in WebSphere Application Server v8.5. For more information, see Migrate 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 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 v8.5, but some extensions are supplied.

• Use of the servlet RunAs function: WAS on the distributed platforms (not the z/OS platform) refers to this function as Delegation Policy. We 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 API or Service Provider Programming Interface (API/SPI) level makes it easier to deploy applications from WebSphere Application Server Network Deployment on z/OS. Features enhanced or deprecated by WebSphere Application Server 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 WebSphere Application Server 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 WAS security APIs: z/OS supports WAS 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