Trusted ID evaluator

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:

Identity assertion trust validation for JAX-RPC

Identity assertion trust validation for JAX-WS

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 requestor login. The requestor 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 requestor. In some cases, there are multiple security tokens, so the service has to decide which one to use. When the requestor 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 requestor username and password is used for authentication. In this case, authentication is performed with requestor properties, therefore a password is required for authentication.
<Signature, null, null>
The requestor signature is used for authentication.
<IDAssertion, Username, null>
The requestor username (without a password) is used to identify the requestor. 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 requestor username (without a password) is used to identify the requestor, 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 requestor username (without a password) is used to identify the requestor, 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 requestor is established using an X.509 certificate. In this case, the X.509 certificate from the requestor 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 requestor 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 requestor is established using an X.509 certificate, and the signature of intermediary is used to authenticate the intermediary.



Related concepts
Overview of platform configuration and bindings
Related tasks
Changing the order of the callers for a token or message part
Related reference
Trusted ID evaluator collection
Trusted ID evaluator configuration settings
Concept topic Concept topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 19, 2011 3:08:41 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-zos&topic=cwbs_trustidevalv6
File name: cwbs_trustidevalv6.html