(ZOS) WAS security for z/OS

WebSphere Application Server for z/OS supports access to resources by clients and servers in a distributed environment. Determine how to control access to these resources and prevent inadvertent or malicious destruction of the system or data.

These are the pieces in the distributed network that consider:

• We must authorize servers to the base operating system services in z/OS. These services include System Authorization Facility (SAF) security, database management, and transaction management.

  • For the server clusters, we must distinguish between controllers and servants. Controllers run authorized system code, so they are trusted. Servants run application code and are given access to resources, so carefully consider the authorization you give servants.

  • We must also distinguish between the level of authority for run-time servers and for our own application servers have. For example, the node needs the authority to start other clusters, while our own application clusters do not need this authority.

• We must authorize clients (users) to servers and objects within servers. The characteristics of each client requires special consideration:
  • Is the client on the local system or is it remote? The security of the network becomes a consideration for remote clients.
  • Will we allow unidentified (unauthenticated) clients to access the system? Some resources on the system might be intended for public access, while others we might need to protect. To access protected resources, clients must establish their identities and have authorization to use those resources.

• Authentication is the process of establishing the identity of a client in a particular context. A client can be an end user, a machine, or an application. The term authentication mechanism in WebSphere Application Server on z/OS refers more specifically to the facility in which WebSphere identifies an authenticated identity, using HTTP and JMX facilities. When configuring a cell, select an authentication mechanism. The choices for authentication mechanism include:
  • Simple WebSphere Authorization Mechanism (SWAM) - only on Base Application Server, not available on the Network Deployment configuration

    SWAM is deprecated in WAS v9.0 and will be removed in a future release.

  • LTPA
  • Kerberos

• Information about users and groups reside in a user registry. In WAS, a user registry authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. Implementation is provided to support multiple operating system or operating environment-based user registries. When configuring a cell, select a single user registry. The user registry can be local or remote. The choices for user registry include:
  • SAF-based local registry (default when a z/OS security product is chosen for administrative security during customization)
  • Standalone LDAP registry - LDAP can be either a local or remote registry
  • Stand-alone custom user registry - A custom user registry is set up to meet unique registry needs. WAS provides a simple user registry sample called the FileBasedRegistrySample.
  • Federated repositories (default when the WAS is chosen for administrative security during customization)

If we need to protect resources, it is critical that you identify who accesses those resources. Thus, any security system requires client (user) identification, also known as authentication. In a distributed network supported by WAS for z/OS, clients can access resources from:

• Within the same system as a server

• Within the same sysplex as the server
• Remote z/OS systems
• Heterogeneous systems, such as WAS on distributed platforms, Customer Information Control System (CICS ), or other Java Platform, Enterprise Edition-compliant systems.

Additionally, clients can request a service that requires a server to forward the request to another cluster. In such cases, the system must handle delegation, the availability of the client identity for use by intermediate clusters and target clusters.

Finally, in a distributed network, how do you verify that messages being passed are confidential and have not been tampered? How do you verify that clients are who they claim to be? How do you map network identities to z/OS identities? These issues are addressed by the following support in WAS for z/OS:

• The use of SSL and digital certificates
• Kerberos
• Common Secure Interoperability, v2 (CSIv2)
• SPNEGO
• Distributed identity mapping feature in SAF

Subtopics

• z/OS Profile Management Tool security settings
  The z/OS Profile Management Tool allows us to specify System Authorization Facility (SAF) profile prefixes (previously referred to as z/OS security domains) for our WAS for z/OS configuration.

• SAF profile prefixes and the customization jobs
  We can configure a System Authorization Facility (SAF) profile prefix (previously referred to as a z/OS security domain) using the z/OS Profile Management Tool.

• System Authorization Facility considerations for the operating system and application levels
  There are a few things to consider when enabling System Authorization Facility (SAF) authorization for the operating system and application levels.

• Authentication mechanisms
  After the systems are up and running, the next step in setting up security is to select an authentication mechanism. An authentication mechanism defines rules about security information (for example, whether a credential is forwardable to another Java process) and the format of how security information is stored in both credentials and tokens. Authentication is the process of establishing whether a client is valid in a particular context. A client can be either an end user, a machine, or an application.

• Specifics about identification and authentication
  For identification, each controller and servant start procedure must have its own user ID and define it in the STARTED class. Because we should give differing resource authorizations to each, we should give differing user IDs to controllers and servants.

• Authorization checking
  Each controller, servant, and client must be associated with an MVS™ user ID. When a request flows from a client to the server or from a server to another server, WAS for z/OS passes the user identity (client or server) with the request. This way, each request is performed on behalf of the user identity and the system checks to see if the user identity has the authority to make such a request.

• Secure Sockets Layer security for WAS for z/OS
  This topic assumes we understand the SSL protocol and how cryptographic services system SSL works on z/OS. SSL is used by multiple components within WAS to provide trust and privacy. Such components include the built-in HTTP transport, the Object Request Broker (ORB) (client and server), and the secure LDAP client. Configuring SSL is different between client and server with WAS. If we want the added security of protected communications and user authentication in a network, we can use SSL security.

• Setting permission for files created by applications
  Files created by applications running in the servant will have permission bits set according to the default umask. To change the default umask for the servant, specify the _BPX_BATCH_UMASK environment variable for the servant. Deployment manager and application servers require group read/write access to the data in their config root.

• RACF protection for DB2
  Use the Resource Access Control Facility (RACF ) DSNR resource class to protect DB2 resources. This helps you centralize security management. This section gives we pointers to general information about setting up RACF protection for DB2 and specific information about the resources, groups, user IDs, and permissions used by WAS for z/OS.

• System Authorization Facility (SAF) profile names
  The Profile Management Tool and the zpmt command generate jobs that help we create the necessary System Authorization Facility (SAF) profiles-such as STARTED, CBIND, or SERVER-that enable the server to run.

Related:

Federated repositories

Prepare for security at installation time

Select a registry or repository

Use distributed identity mapping for SAF

PropFilePasswordEncoder command reference