Identity assertion

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 authorization checks the credential to determine whether access is permitted, it also sets the invocation credential so that if the enterprise bean method calls another enterprise bean method that is located on another server, the invocation credential can be used as the identity 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 invocation credential identity is sent to the downstream server in an identity token. In addition, the sending server identity, including password or token, is sent in the client authentication token. Both tokens are needed by the receiving server to accept the asserted identity. The receiving server completes certain actions to accept the asserted identity.

First, the server determines whether the sending server identity is located on the trusted principal list of the receiving server. In other words, can the sending server send an identity token to the receiving server? After you determine that the sending server is on the trusted list, ensure that the server is the sending server by authenticating it. Authenticate the server by comparing the user ID and password from the sending server to that of the receiving server, or it could require a real authenticate call. If the credentials of the sending server are authenticated and the server is on the trusted principal list, then proceed to evaluate the identity token.

There are four formats of identities which can be present in an identity token:

The product server that receives authentication information typically supports all four identity types. The sending server decides which one is chosen based on how the original client was authenticated. The type that is present depends on how the client originally authenticates to the sending server. For example, if the client uses SSL client authentication to authenticate to the sending server, then the identity token to the downstream server contains the certificate chain. This information is important because it permits the receiving server to perform its own certificate chain mapping. It enables more interoperability 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 maps one-to-one with the user ID fields. For an ITTDistinguishedName identity token, the mapping depends on the user registry. For LDAP, the configured search filter determines how the mapping occurs. For LocalOS, the first attribute of the DN (typically the same as the common name) maps to the user ID of the registry.

Some user registry methods are called to gather additional credential information that used by authorization. In a stateful server, this is done one time for the sending server and receiving server pair where the identity tokens are the same. Subsequent requests are made through a session ID.

Identity Assertion is only available using the CSIv2 protocol.