Trusted ID evaluator
A trusted ID evaluator is the mechanism that evaluates whether a given ID name is trusted.
Use the trusted ID evaluator with JAX-RPC
In JAX-RPC, 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 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, WAS 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 containing the identity and a password. Server s2 receives the request, authenticates the user using a 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 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. We might also use identity assertion for interoperability with another Web Services Security implementation.
Depending upon the implementation of JAX-RPC, we can use various types of infrastructure to store a list of the trusted IDs, such as:
- Plain text file
- Database
- 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.
Use 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 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 WAS v6.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.
Related tasks