(zos)

Use CBIND to control access to clusters

Use the CBIND class in RACF to restrict a client's ability to access clusters from Java Application Clients or J2EE compliant servers. We must have READ permission to access clusters.

We can also use this class to specify which servers are trusted to assert identities (with no authenticator).

Remember: When using the server trusted identity, the RACF server id needs to be granted CONTROL permission to the profile.

• z/OS Secure Authentication Services (z/SAS) identity assertion accepted

• CSIv2 (CSIv2) identity assertion

• Web container HTTP transport

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.

This validates an intermediate server to send certificates (MutualAuthCBindCheck=true). We can deactivate the class if we do not require this kind of access control.

Servers are either clustered or not clustered. The value of cluster_name is:

1. For a clustered server, the cluster_name used in these profiles is the cluster short name.

2. For an unclustered server, instead of a cluster_name a server custom property (ClusterTransitionName) is used.

When you convert a server into a clustered server the ClusterTransitionName becomes the short name of the cluster. The following steps explain the CBIND authorization checking by WebSphere Application Server for z/OS.

1. Use the CBIND class in RACF to restrict the ability of a client to access clusters, or we can deactivate the class if we do not require this kind of access control. WebSphere Application Server for z/OS uses two types of profiles in the CBIND class. One type of profile controls whether a local or remote client can access clusters. The name of the profile has the following form, where cluster_name is the name of the cluster, and SAF_profile_prefix is the prefix used for SAF profiles.
   CB.BIND.<optional SAF_profile_prefix>.<cluster_name>

   When we add a new cluster, you must authorize all Java Client user IDs and Servers to have read access to the CB.cluster_name and CB.BIND.cluster_name RACF profiles.

   
   Example: WSADMIN needs read authority to the CB.BBOC001 and CB.BIND.BBOC001 profiles:

   PERMIT CB.BBOC001      CLASS(CBIND) ID(WSADMIN) ACCESS(READ)
   PERMIT CB.BIND.BBOC001 CLASS(CBIND) ID(WSADMIN) ACCESS(READ)

2. We can also use the System Authorization Facility (SAF) CBIND class to indicate that a process is trusted to assert identities to WebSphere Application Server for z/OS. This usage is primarily intended for use by trusted intermediate servers who have already authenticated their callers. The intermediate server (or process) must establish its network identity to WebSphere Application Server for z/OS using SSL client certificates. This network identity is mapped to an MVS user ID by SAF security service. This mapped identity must be granted CONTROL access to the CB.BIND.<optional SAF_profile_prefix>.<cluster_name> process to be authorized to assert identities. The use of CBIND profiles to establish trust is used by the following authentication mechanisms:

   • Web container HTTP transport (which validates unencrypted client certificates when the property: MutualAuthCBindCheck=true is set)

   • CSIv2 identity assertion for IIOP

   • z/SAS identity assertion accepted

   For example, WEBSERV must assert client certificates that are received from its callers: PERMIT CB.BIND.BBOC001 CLASS(CBIND) ID(WEBSERV) ACCESS(CONTROL)

Related concepts

System Authorization Facility for role-based authorization

Cluster authorizations

Server process authorization checking