Identity assertion to the downstream server
When a client authenticates to a server, the received credential is set. When the authorization engine checks the credential to determine whether access is permitted, it also sets the invocation credential . Identity assertion is the invocation credential that is asserted to the downstream server.
When a client authenticates to a server, the received credential is set. When the authorization engine checks the credential to determine whether access is permitted, it also sets the invocation credential so that if the Enterprise JavaBeans (EJB) method calls another EJB method that is on other servers, the invocation credential can be the identity that is used to start the downstream method. Depending on the RunAs mode for the enterprise beans, the invocation credential is set as the originating client identity, the server identity, or a specified different identity. Regardless of the identity that is set, when identity assertion is enabled, it is the invocation credential that is asserted to the downstream server.
The invocation credential identity is sent to the downstream server in an identity token. In addition, the sending server identity, including the password or token, is sent in the client authentication token when basic authentication is enabled. The sending server identity is sent through a Secure Sockets Layer (SSL) client certification authentication when client certificate authentication is enabled. Basic authentication takes precedence over client certificate authentication.
- The identity of the sending server sent to the receiving server is either a GSSUP token (user ID and password) or an SSL client certificate. On z/OS®, the MVS™ started task id is sent instead of the GSSUP token when the active user registry is local OS and SAF authorization is enabled.
- Trust is established between the sending and receiving server depending
on what identity is being sent.
- When a GGSUP token is sent, the trust is established by verifying that the sending server identity is on the trusted principal list of the receiving server.
- When the MVS started task id is sent, the trust is established by verifying that this id has UPDATE authority to the CB.BIND.<servername> profile in the SAF database.
- When an SSL client certificate is sent, on z/OS this certificate is mapped to a Service Access Facility (SAF) user ID. The trust is established by verifying that this user ID has the UPDATE authority to the CB.BIND.<servername> profile.
- After it is determined that the sending server is on the trusted list, the server authenticates the sending server to verify its identity.
- The server is authenticated by comparing the user ID and password from the sending server to the receiving server. If the credentials of the sending server are authenticated and trusted, then the server proceeds to evaluate the identity token.
- The receiving server checks its defined user registry for the
presence of the asserted user ID to gather more credential information
for authorization purposes (for example, group memberships). Thus,
the receiving server's user registry must contain all of the asserted
user IDs. Otherwise, identity assertion is not possible. In a stateful
server, this action occurs once for the sending server and the receiving
server pair where the identity tokens are the same. Subsequent requests
are made through a session ID.Note: When the downstream server does not have a user registry with access to the asserted user IDs in its repository, do not use identity assertion because authorization checks will fail. By disabling identity assertion, the authorization checks on the receiving server are not needed.
The target server validates the authority of the sending server to assert an identity by the client certificate. The client certificate is mapped to a Service Access Facility (SAF) user ID, either by using the RACDCERT MAP filters or the RACMAP filters defined in the SAF database. The SAF user ID must have UPDATE authority for the CB.BIND.<optionSAFProfilePrefix>.cluster_short_name profile in the CBIND class. If a client certificate is not sent, the CBIND check is performed against the started task ID of the sending server.
- Principal name
- Distinguished name
- Certificate chain
- Anonymous identity
After the identity format is understood and parsed, the identity maps to a credential. For an ITTPrincipal identity token, this identity maps one-to-one with the user ID fields.
For an ITTDistinguishedName identity token, the mapping depends on the user registry. For Lightweight Directory Access Protocol (LDAP), the configured search filter determines how the mapping occurs. For LocalOS, the first attribute of the distinguished name (DN), which is typically the same as the common name, maps to the user ID of the registry.
ITTDistinguishedName identity tokens and ITTCertChain identity tokens are mapped in the same way. Both types of identity tokens use a certificate that is mapped to a SAF user ID by using the RACDCERT or equivalent mapping functions, like RACMAP filters. The mapping can be based on the Subject name or the Issuers name.
Identity assertion is only available by using the Common Secure Interoperability Version 2 (CSIv2) protocol.