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.
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:
- The server determines whether the sending server identity, sent
with a basic authentication token or with an SSL client certificate,
is on the trusted principal list of the receiving server. The server
determines whether the sending server can send an identity token to
the receiving server.
- 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 on the trusted principal
list, then the server proceeds to evaluate the identity token.
- The downstream server checks its defined user registry for the
presence of the asserted user ID to gather additional credential information
for authorization purposes (for example, group memberships). Thus,
the downstream 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 downstream 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. 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:
- Principal name
- Distinguished name
- Certificate chain
- Anonymous identity
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.
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.
Note: There is a restriction for using identity assertion with
KRB token to downstream. If you use identity assertion with Kerberos
enabled, the identity assertion does not have the Kerberos authentication
token (KRBAuthnToken) when going to downstream servers. It uses LTPA
for authentication instead.