Using CBIND to control access to clusters
You can use the CBIND class in RACF to restrict a client's ability
to access clusters from Java Application Clients or other J2EE compliant servers.
You will need READ permission to access clusters.
You can also use this class to specify which servers are trusted to assert
identities (with no authenticator):
- z/SAS Identity Assertion accepted
- CSIv2 Identity Assertion
- Web Container HTTP Transport
This validates an intermediate server to send certificates (MutualAuthCBindCheck=true).
You can deactivate the class if you do not require this kind of access control.
Servers are either clustered or not clustered. The value of cluster_name
is:
- For a clustered server, the cluster_name used in these profiles is the
cluster short name.
- For an unclustered server, instead of a cluster_name a server custom property
(ClusterTransitionName) is used.
Note: When you convert a server into a clustered server the ClusterTransitionName
becomes the cluster's short name.
The following explains the CBIND authorization checking by WebSphere Application
Server for z/OS.
- You can use the CBIND class in RACF to restrict a client's ability to
access clusters, or you can deactivate the class if you do not require this
kind of access control. There are two types of profiles WebSphere Application
Server for z/OS uses in the CBIND class:
- One that controls whether a local or remote client can access clusters.
The name of the profile has this form:
CB.BIND.
cluster_name
where cluster_name is the name of the cluster.
- One that controls whether a client can invoke J2EE applications in a
cluster. The name of the profile has this form:
CB.
cluster_name
where cluster_name is the name of the cluster.
Note: When you 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)
- You can also use the 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.cluster_name process
in order 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 needs to assert client certificates received from
its callers: PERMIT CB.BBOC001 CLASS(CBIND) ID(WEBSERV) ACCESS(CONTROL)
Refer to EJBROLES and GEJBROLES for
more information.

Authorization checking
EJBROLES and GEJBROLES
Cluster authorizations

Specifics about server process authorization checking
Searchable topic ID:
csecsafauth
Last updated: Jun 21, 2007 9:56:50 PM CDT
WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/csec_safauth.html