(ZOS) Security considerations for WAS for z/OS

Functions supported on WAS for z/OS

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

Function	Additional information
RunAs EJB	See Delegations.
RunAs for Servlets	See Delegations.
SAF-based IIOP Protocols	See CSIv2 and SAS client configuration.
z/OS connector facilities	See Resource Recovery Services (RRS).
Administrative security	See Administrative security.
Application security	See Application security.
Java 2 security	See Java 2 security.
Disable security	See Disable administrative security.
SAF keyrings	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	See Task overview: Securing resources.
Web authentication (LTPA)	See Configure the LTPA mechanism.
IIOP using LTPA	See LTPA.
WebSphere application bindings	WebSphere application bindings can be used to provide user to role mappings.
Synch to OS Thread	See Java thread identity and an operating system thread identity.
SAF registries	See Select a registry or repository.
Identity assertion	See Identity assertion.
Authentication protocols	Example: z/SAS, CSIV2 See Authentication protocol support.
CSIv2 conformance level "0"	See Security planning overview.
JAAS programming model WebSphere extensions	See Use the JAAS programming model for web authentication.
Distributed identity mapping using SAF	See Distributed identity mapping using SAF

All basic WASs 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: WAS ND 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 v6.0.x and previous version servers that have been federated in a v6.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 v9.0 as offered in v5.
• 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 Simple WebSphere Authentication Mechanism (SWAM) is supported.

  SWAM is deprecated in WAS v9.0 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 WAS for z/OS with other WAS 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, 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 WAS v9.0 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 WAS v9.0. For more information, see Migrate Common Object Request Broker Architecture programmatic login to JAAS (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, v5 is shipped with WebSphere Version v9.0, 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 WAS ND at the API/SPI level

Compliance with WAS ND at the application programming interface or Service Provider Programming Interface (API/SPI) level makes it easier to deploy applications from WAS ND on z/OS. Features enhanced or deprecated by WAS ND are enhanced or deprecated by z/OS. However, this does not mean there is no migration for z/OS customers. Compliance with WebSphere WAS ND at the API/SPI level includes:

• WAS 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. WAS 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).

Task overview: Securing resources