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.
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 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.
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.
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.
Identity
assertion is only available by using the Common Secure Interoperability
Version 2 (CSIv2) protocol.
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.