You can use the CBIND class in RACF to restrict a
client's ability to access clusters from Java Application Clients or J2EE
compliant servers. You must have READ permission to access clusters.
Before you begin
You 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
- Common Secure Interoperability Version 2 (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.
About this task
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 short name of the cluster.
The following steps explain the
CBIND authorization checking by WebSphere Application Server for z/OS.
Procedure
- You can use the CBIND class in RACF to restrict the ability of
a client to access clusters, or you can deactivate the class if you 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.
CB.BIND.
cluster_name
Another type of profile controls whether
a client can invoke J2EE applications in a cluster. The name of the profile
has the following form, where cluster_name is the name of the cluster.CB.
cluster_name
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 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.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)