1) What is a Security Token Service?
An informal description of a Security Token Service is that it is a web service that offers some or all of the following services (amongst others):
- It can issue a Security Token of some sort based on presented or configured credentials.
- It can say whether a given Security Token is valid or not
- It can renew (extend the validity of) a given Security Token
- It can cancel (remove the validity of) a given Security Token
- It can transform a given Security Token into a Security Token of a different sort.
A client can communicate with the STS via a protocol defined in the WS-Trust specification. The SOAP Body of the request contains a "RequestSecurityToken" element that looks like:
<wst:RequestSecurityToken Context="..." xmlns:wst="...">
<wst:TokenType>...</wst:TokenType>
<wst:RequestType>...</wst:RequestType>
<wst:SecondaryParameters>...</wst:SecondaryParameters>
...
</wst:RequestSecurityToken>
The Apache CXF STS implementation supports a wide range of parameters that are passed in the RequestSecurityToken element. The SOAP Body of the response from the STS will contain a "RequestSecurityTokenResponse(Collection)" element, e.g.:
<wst:RequestSecurityTokenResponseCollection xmlns:wst="...">
<wst:RequestSecurityTokenResponse>
...
</wst:RequestSecurityTokenResponse>
</wst:RequestSecurityTokenResponseCollection>
1.1 A sample request/response for issuing a Security Token
A sample client request is given here, where the client wants the STS to issue a SAML 2.0 token for the "http://cxf.apache.org:8080/service" service:
<wst:RequestSecurityToken Context="..." xmlns:wst="...">
<wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
</wst:TokenType>
<wst:RequestType>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
</wst:RequestType>
<wsp:AppliesTo>http://cxf.apache.org:8080/service</wsp:AppliesTo>
</wst:RequestSecurityToken>
The STS responds with:
<wst:RequestSecurityTokenResponseCollection xmlns:wst="...">
<wst:RequestSecurityTokenResponse>
<wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
</wst:TokenType>
<wst:RequestedSecurityToken>
<saml2:Assertion xmlns:saml2="..." ... />
</wst:RequestedSecurityToken>
</wst:RequestSecurityTokenResponse>
</wst:RequestSecurityTokenResponseCollection>
2) The STS provider framework in Apache CXF
The first support for an STS in Apache CXF appeared in the 2.4.0 release with the addition of an STS provider framework in the WS-Security module. This is essentially an API that can be used to create your own STS implementation. As the STS implementation shipped in CXF 2.5 is based on this provider framework, it makes sense to examine it in more detail.
The SEI (Service Endpoint Interface) is available here. It contains the following methods that are relevant to the STS features discussed above:
- RequestSecurityTokenResponseCollectionType issue(RequestSecurityTokenType request) - to issue a security token
- RequestSecurityTokenResponseType issueSingle( RequestSecurityTokenType request) - to issue a security token that is not contained in a "Collection" wrapper (for legacy applications).
- RequestSecurityTokenResponseType cancel(RequestSecurityTokenType request) - to cancel a security token
- RequestSecurityTokenResponseType validate(RequestSecurityTokenType request) - to validate a security token
- RequestSecurityTokenResponseType renew(RequestSecurityTokenType request) - to renew a security token
Significant updates to the STS Provider framework after the CXF 2.4.0 release include support for SOAP 1.2, a major bug fix to support operations other than issue, better exception propagation, and adding support for the WS-Trust 1.4 schema. These features are all available in the Apache CXF 2.4.3 release onwards.
Hi Colm,
ReplyDeleteThanks for the post. As I understand this is very similar to OAuth style of issuing and authentication verification via token. Am I correct ? And is STS only available for JAX-WS ?
Hi Ramesh,
ReplyDeleteYes, the STS is only available for JAX-WS, as all communication follows the WS-Trust standard. What use-cases are you interested in?
Colm.
hello Colm, i'm looking a way for using usernamatoken profile but not validating username password for every call i need a solution that i can authenticate for a time period and for every call in that period get ws context with cached session like token. What is a standart way to do this for jax-ws
ReplyDeleteOne option would be to have the clients authenticate to an STS instead, which would issue a SAML token to the client, which the client then includes in the service call. The client caches the token for as long as the token is valid. This is the standard WS-Trust way of doing things.
Delete