- Identity assertion (attribute layer).
When selected,
this server
accepts identity tokens from upstream servers. If the server receives
an identity token, the identity is taken from an originating client.
For example, the identity is in the same form that the originating
client presented to the first server. An upstream server sends the
identity of the originating client. The format of the identity can
be either a principal name, a distinguished name, or a certificate
chain. In some cases, the identity is anonymous. It is important to
trust the upstream server that sends the identity token because the
identity authenticates on this server. Trust of the upstream server
is established either using Secure Sockets Layer (SSL) client certificate
authentication or basic authentication. You must select one of the
two layers of authentication in both inbound and outbound authentication
when you choose identity assertion.
The server
ID is sent in the client authentication token with the identity token.
The server ID is checked against the trusted server ID list. If the
server ID is on the trusted server list, the server ID is authenticated.
If the server ID is valid, the identity token is put into a credential
and used for authorization of the request.
Note: If your
configured registry is Local OS, then the trust is instead established
by checking if the upstream server identity is authorized on the downstream
server with UPDATE authority to the CBIND class, profile CB.BIND.<optionalSAFProfilePrefix>.<cluster_short_name>.
The upstream server identity is sent using an SSL client certificate.
If SSL is not used, the CBIND check is performed against the started
task identity of the upstream server.
Avoid trouble: When identity assertion is enabled, message layer
or transport layer should be enabled also. For server-to-server communication,
besides enabling transport layer/client authentication, identity assertion
or message layer should be enabled also.
gotcha
For more information,
refer to Identity assertion.
- Message layer:
Basic authentication (GSSUP):
This
type of authentication is the most typical. The user ID and password
or authenticated token is sent from a pure client or from an upstream
server. When a user ID and password are received at the server, they
are authenticated with the user registry of the downstream server.
Lightweight
Third Party Authentication (LTPA):
In this case, an LTPA
token is sent from the upstream server. Note that if you choose LTPA,
then both servers must share the same LTPA keys
Kerberos
(KRB5):
To select Kerberos, the active authentication mechanism
must be Kerberos. In this case, a Kerberos token is sent from the
upstream server.
For more information, read about Message layer
authentication.
- Secure Sockets Layer client certificate
authentication (transport
layer).
The SSL client certificate is used to authenticate instead
of using user ID and Password. If a server delegates an identity to
a downstream server, the identity comes from either the message layer
(a client authentication token) or the attribute layer (an identity
token), and not from the transport layer through the client certificate
authentication.
A client has an SSL
client certificate that is stored in the keystore file of the client
configuration. When SSL client authentication is enabled on this server,
the server requests that the client send the SSL client certificate
when the connection is established. The certificate chain is available
on the socket whenever a request is sent to the server. The server
request interceptor gets the certificate chain from the socket and
maps this certificate chain to a user in the user registry. This type
of authentication is optimal for communicating directly from a client
to a server. However, when you have to go downstream, the identity
typically flows over the message layer or through identity assertion.
A client has
an SSL client certificate that is stored in the key ring file of the
client configuration. When SSL client authentication is enabled on
this server, the server requests that the client send the SSL client
certificate when the connection is established. The certificate chain
is available on the socket whenever a request is sent to the server.
The server request interceptor gets the certificate chain from the
socket and maps this certificate chain to a user in the user registry.
This type of authentication is optimal for communicating directly
from a client to a server. However, when you have to go downstream,
the identity typically flows over the message layer or through identity
assertion.