SOAP-MSG protected by WS-Security has 3 possible issues in regards to SECURITY TOKEN.
- Security Token format incompatibility
- Security Token trust
- Namespace differences
WS-TRUST addresses these issues by introducing a STS (Secure Token Service).
Example Scenario: –
In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine if they can “trust” the asserted credentials of the other party. WS-TRUST specification defines extensions to [WS-Security] that provide:
· Methods for issuing, renewing, and validating security tokens.
· Ways to establish, assess the presence of, and broker trust relationships
The goal of WS-Trust is to enable applications to construct trusted [SOAP] message exchanges. This trust is represented through the exchange and brokering of security tokens. This specification provides a protocol agnostic way to issue, renew, and validate these security tokens.
Web Services Trust Model
1. IBM® Tivoli® Federated Identity Manager provides an implementation of the WS-Trust specification. It acts as a STS.
2. Security Token Generation can be done by configuring WAS
1. Client understands X.509 certificates only.
2. Service understands SAML only.
- SOAP Gateway recognizes that it must map to SAML, so it contacts the STS.
- The STS sends back the token in the requested format.
- The gateway formats and sends the message for the service.
WS-TRUST addresses the security token needs of SOAP messages as
1. Format: An STS is used to exchange tokens into formats understandable by recipients.
2. Trust: The STS issues signed tokens forming the basis of trust for entities with which it has formed a trust relationship.
3. Namespace: The STS will return tokens in appropriate syntax for the recipient.
Discussions welcome. The doc. was created for introductory purposes.
Anything you wish should be added / removed / changed ? plz. let me know.
the doc. can be found here : WS – TRUST