[b]Introduction to WS-Trust[/b]
[u]Overview[/u]
The WS-Trust standard is based around a centralized security server (the [color=blue]Security Token Service[/color]), which is capable of authenticating clients and can issue tokens containing various kinds of authentication and authorization data.
[u]WS-Trust specification[/u]
The WS-Trust features of Artix are based on the WS-Trust standard from Oasis:
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html
[u]Supporting specifications[/u]
Apart from the WS-Trust specification itself, several other specifications play an important role in the WS-Trust architecture, as follows:
WS-SecurityPolicy 1.2
SAML 2.0
Username Token Profile
X.509 Token Profile
SAML Token Profile
Kerberos Token Profile
[u]WS-Trust architecture[/u]
Figure 8.1 shows a general overview of the WS-Trust architecture.
[img]http://fusesource.com/docs/esb/4.4/cxf_security/images/ws_trust_01.gif[/img]
Figure 8.1. WS-Trust Architecture
WS-Trust Architecture
[u]Requestor[/u]
A requestor is an entity that tries to invoke a secure operation over a network connection. In practice, a requestor is typically a Web service client.
[u]Relying party[/u]
A relying party refers to an entity that has some services or resources that must be secured against unauthorized access. In practice, a relying party is typically a Web service.
[Note] Note
This is a term defined by the SAML specification, not by WS-Trust.
[u]Security token[/u]
A security token is a collection of security data that a requestor sends inside a request (typically embedded in the message header) in order to invoke a secure operation or to gain access to a secure resource. In the WS-Trust framework, the notion of a security token is quite general and can be used to describe any block of security data that might accompany a request.
In principle, WS-Trust can be used with the following kinds of security token:
SAML token.
UsernameToken token.
X.509 certificate token.
Kerberos token.
[u]SAML token[/u]
A SAML token is a particularly flexible kind of security token. The SAML specification defines a general-purpose XML schema that enables you to wrap almost any kind of security data and enables you to sign and encrypt part or all of the token.
SAML is a popular choice of token to use in the context of WS-Trust, because SAML has all of the necessary features to support typical WS-Trust authentication scenarios.
[u]Claims[/u]
A SAML security token is formally defined to consist of a collection of claims. Each claim typically contains a particular kind of security data.
[u]Policy[/u]
In WS-Trust scenarios, a policy can represent the security configuration of a participant in a secure application. The requestor, the relying party, and the security token service are all configured by policies. For example, a policy can be used to configure what kinds of authentication are supported and required.
[u]Security token service[/u]
The security token service (STS) lies at the heart of the WS-Trust security architecture. In the WS-Trust standard, the following bindings are defined (not all of which are supported by Apache CXF):
Issue binding—the specification defines this binding as follows: Based on the credential provided/proven in the request, a new token is issued, possibly with new proof information.
Validate binding—the specification defines this binding as follows: The validity of the specified security token is evaluated and a result is returned. The result may be a status, a new token, or both.
Renew binding—the specification defines this binding as follows: A previously issued token with expiration is presented (and possibly proven) and the same token is returned with new expiration semantics.
Cancel binding—the specification defines this binding as follows: When a previously issued token is no longer needed, the Cancel binding can be used to cancel the token, terminating its use.
[u]Overview[/u]
The WS-Trust standard is based around a centralized security server (the [color=blue]Security Token Service[/color]), which is capable of authenticating clients and can issue tokens containing various kinds of authentication and authorization data.
[u]WS-Trust specification[/u]
The WS-Trust features of Artix are based on the WS-Trust standard from Oasis:
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html
[u]Supporting specifications[/u]
Apart from the WS-Trust specification itself, several other specifications play an important role in the WS-Trust architecture, as follows:
WS-SecurityPolicy 1.2
SAML 2.0
Username Token Profile
X.509 Token Profile
SAML Token Profile
Kerberos Token Profile
[u]WS-Trust architecture[/u]
Figure 8.1 shows a general overview of the WS-Trust architecture.
[img]http://fusesource.com/docs/esb/4.4/cxf_security/images/ws_trust_01.gif[/img]
Figure 8.1. WS-Trust Architecture
WS-Trust Architecture
[u]Requestor[/u]
A requestor is an entity that tries to invoke a secure operation over a network connection. In practice, a requestor is typically a Web service client.
[u]Relying party[/u]
A relying party refers to an entity that has some services or resources that must be secured against unauthorized access. In practice, a relying party is typically a Web service.
[Note] Note
This is a term defined by the SAML specification, not by WS-Trust.
[u]Security token[/u]
A security token is a collection of security data that a requestor sends inside a request (typically embedded in the message header) in order to invoke a secure operation or to gain access to a secure resource. In the WS-Trust framework, the notion of a security token is quite general and can be used to describe any block of security data that might accompany a request.
In principle, WS-Trust can be used with the following kinds of security token:
SAML token.
UsernameToken token.
X.509 certificate token.
Kerberos token.
[u]SAML token[/u]
A SAML token is a particularly flexible kind of security token. The SAML specification defines a general-purpose XML schema that enables you to wrap almost any kind of security data and enables you to sign and encrypt part or all of the token.
SAML is a popular choice of token to use in the context of WS-Trust, because SAML has all of the necessary features to support typical WS-Trust authentication scenarios.
[u]Claims[/u]
A SAML security token is formally defined to consist of a collection of claims. Each claim typically contains a particular kind of security data.
[u]Policy[/u]
In WS-Trust scenarios, a policy can represent the security configuration of a participant in a secure application. The requestor, the relying party, and the security token service are all configured by policies. For example, a policy can be used to configure what kinds of authentication are supported and required.
[u]Security token service[/u]
The security token service (STS) lies at the heart of the WS-Trust security architecture. In the WS-Trust standard, the following bindings are defined (not all of which are supported by Apache CXF):
Issue binding—the specification defines this binding as follows: Based on the credential provided/proven in the request, a new token is issued, possibly with new proof information.
Validate binding—the specification defines this binding as follows: The validity of the specified security token is evaluated and a result is returned. The result may be a status, a new token, or both.
Renew binding—the specification defines this binding as follows: A previously issued token with expiration is presented (and possibly proven) and the same token is returned with new expiration semantics.
Cancel binding—the specification defines this binding as follows: When a previously issued token is no longer needed, the Cancel binding can be used to cancel the token, terminating its use.