A trusted ID evaluator is the mechanism that evaluates
whether a given ID name is trusted.
Using the trusted ID evaluator with the JAX-RPC programming
model
In the JAX-RPC programming model, the trusted ID evaluator,
com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl, is an abstraction
of the mechanism that evaluates whether a given ID name is trusted.
There are two trust modes for validating the trust of the upstream
server when using JAX-RPC:
- Basic authentication (username token)
- The upstream server sends a username token with a user name and
password to a downstream server. The consumer or receiver of the message
authenticates the username token and validates the trust based upon
the TrustedIDEvaluator implementation. The TrustedIDEvaluator implementation
must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator Java interface.
- Signature
- The upstream server signs the message, which can be any message
part such as the SOAP body. The upstream server sends the X.509 token
to a downstream server. The consumer or receiver of the message verifies
the signature and validates the X.509 token. The identity or the distinguished
name from the X.509 token that is used in the digital signature is
validated based on the TrustedIDEvaluator implementation. The TrustedIDEvaluator
implementation must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator Java interface. For the X.509 certificate, WebSphere® Application Server uses the distinguished
name in the certificate as a requester identity.
The following figures demonstrate the identity
assertion trust process for both programming models:


In this figure, server s1 is
the upstream server and identity assertion is set up between server s1 and
server s2. The s1 server authenticates
the identity called bob. Server s1 wants to
send bob to the s2 server with a password.
The trust mode is an s1 credential that contains
the identity and a password. Server s2 receives the
request, authenticates the user using a Java Authentication
and Authorization Service (JAAS) login module, and uses the trusted
ID evaluator to determine whether to trust the identity. If the identity
is trusted, bob is used as the caller that invokes the service.
If authorization is required, bob is the identity that is used
for authorization verification.
The identity can be asserted
as the RunAs (invocation) identity of the current security context.
For example, the web services gateway authenticates a requester using
a secure method such as password authentication and then sends the
requester identity only to a back-end server. You might also use identity
assertion for interoperability with another Web Services Security
implementation.
Depending upon the implementation of JAX-RPC,
you can use various types of infrastructure to store a list of the
trusted IDs, such as:
- Plain text file
- Database
- Lightweight Directory Access Protocol (LDAP) server
The trusted ID evaluator is typically used by the eventual
receiver in a multi-hop environment. The Web Services Security implementation
invokes the trusted ID evaluator and passes the identity name of the
intermediary as a parameter. If the identity is evaluated and deemed
trustworthy, the procedure continues. Otherwise, an exception is created
and the procedure is stopped.
Using the trusted ID evaluator with the JAX-WS programming
model
In the JAX-WS programming model, the same concepts
are supported for the trusted ID evaluator, although the implementation
is different. For the JAX-WS run time, use the administrative console
to select the Use identity assertion option
on the caller binding panel. This defines the trusted identity token
type, and then defines a list of one or more trusted identities. The
trusted ID evaluator validates the trusted identity token against
the list of trusted identities. For more information about the list
of trusted identities, read the topic Changing the order of the callers
for a token or message part.
For WebSphere Application
Server Version 6.1 and later, the Caller and TrustMethod elements
are used to support the requester login. The requester sends a message
to an intermediary, and the message is dispatched to the service.
Based on the security information, the service performs a login for
the requester. In some cases, there are multiple security tokens,
so the service has to decide which one to use. When the requester
ID is included as an ID assertion, the service can specify how to
trust the intermediary. The following intermediary scenarios are supported:
- <BasicAuth, null, null>
- The requester username and password is used for authentication.
In this case, authentication is performed with requester properties,
therefore a password is required for authentication.
- <Signature, null, null>
- The requester signature is used for authentication.
- <IDAssertion, Username, null>
- The requester username (without a password) is used to identify
the requester. The UsernameToken token is used as the ID assertion,
therefore no password is required to accompany the username. In this
case, the service trusts the intermediary unconditionally.
- <IDAssertion, Username, Username>
- The requester username (without a password) is used to identify
the requester, and the username and password of the intermediary is
used to authenticate the intermediary. The UsernameToken token, when
used to establish trusted identity, always requires a password because
the purpose of the token is to establish trust between the intermediary
and the service.
- <IDAssertion, Username, X509>
- The requester username (without a password) is used to identify
the requester, and the signature of the intermediary is used to authenticate
the intermediary. In this case, the trusted identity for the signature
of the intermediary must be established using an X.509 certificate.
- <IDAssertion, X509, null>
- The identity of the requester is established using an X.509 certificate.
In this case, the X.509 certificate from the requester does not provide
a signature to prove possession of the certificate, and therefore
the service trusts the intermediary unconditionally.
- <IDAssertion, X509, Username>
- The identity of the requester is established using an X.509 certificate,
and the username and password of the intermediary is used to authenticate
the intermediary. The UsernameToken token, when used to establish
trusted identity, always requires a password because the purpose of
the token is to establish trust between the intermediary and the service.
- <IDAssertion, X509, X509>
- The identity of the requester is established using an X.509 certificate,
and the signature of intermediary is used to authenticate the intermediary.