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 located on other servers, the invocation credential can be the identity used to invoke 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.

[AIX HP-UX Linux Solaris Windows] 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.

[z/OS] The sending server identity is sent using an SSL client certificate. If SSL is not used, the server identity is not sent.

Both identity tokens are needed by the receiving server to accept the asserted identity. The receiving server completes the following actions to accept the asserted identity:

[z/OS] 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. The user ID must have update authority for the CBIND.servername profile. If a client certificate is not sent, the CBIND check is performed against the default user ID.

Evaluation of the identity token consists of the following four identity formats that exist in an identity token: The product servers that receive authentication information typically support all four identity types. The sending server decides which one is chosen, based on how the original client authenticated. The existing type depends on how the client originally authenticates to the sending server. For example, if the client uses Secure Sockets Layer (SSL) client authentication to authenticate to the sending server, then the identity token sent to the downstream server contains the certificate chain. With this information, the receiving server can perform its own certificate chain mapping and interoperability is increased with other vendors and platforms.

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.

[AIX HP-UX Linux Solaris Windows] 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.

[AIX HP-UX Linux Solaris Windows] For an ITTCertChain identity token, see the Map certificates to users section for details on how this action is performed for the LDAP user registry. For LocalOS, the first attribute of the DN in the certificate is used to map to the user ID in the registry.

[z/OS] 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 using the RACDCERT or equivalent mapping functions. The mapping can be based on the Subject name or the Issuers name.

[AIX HP-UX Linux Solaris Windows] Identity assertion is only available using the Common Secure Interoperability Version 2 (CSIv2) protocol.




Related concepts
Authentication protocol for EJB security
Related tasks
Authenticating users
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=cseccsiv2ida
File name: csec_csiv2ida.html