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.