WSO2 Security Token Service is shipped as the Resident Identity Provider of WSO2 Identity Server. The responsibility of a Security Token Service (aka STS) is to provide tokens that are trusted by a relying party to a requester – the service consumer.
There is a terminology goes with the article :
- RST – Request for a Security Token. This is the initial request sent by a requester to a STS requesting for a security token. Basically This is a XML tag introduced at ws-trust specification.
- RSTR – Response for a Security Token Request. This is the response issued by the STS along with a signed security token to the requested party.
- Claim – A statement made about something. ie : <email>email@example.com</email> is a claim about client’s email address.
- Relying Party : The service provider who is trusting the security token service. In the picture ‘Web Service’ (I preferred to call it as ‘Relying Party’ since STS is also a service provider as well as a web service which can be described with WSDL)
The Big Picture
The communication paths are showed by arrows.
- requester may grant a security token by sending a RST to the STS or from a third party.
- Then the token is submitted to the relying party to access it’s services.
- The Web service either trusts the issuing security token service or may request a token service to validate the token (or the Web service may validate the token itself).
Lets simulate the scenario with WSO2 identity Server. According to the specification there are three parties communicating to each other trusting each other. The cast crew in the real world will be,
- STS – WSO2 Identity Server’s resident identity provider (WSO2 STS)
- Relying Party – Echo Service of WSO2 ESB
- Requester – STS Sample Client
Run WSO2 Identity Server on the default port (9443). Please refer Getting Started guide to download and run the product. Please note we are using the latest version of Identity Provider which is IS 5.1.0 at the moment. The directions may be differed according to the version.
Move to Resident Identity Provider from Main > Identity Providers > List > Resident Identity Provider
Then set inbound authentication properties by giving username token to authenticate requesters before issuing tokens. Then we can secure the STS from issuing tokens to every Tom, Dick and Harry who send RSTs.
Go to Apply Security Policy and select UserNameToken (In this security Scenario, the requester should submit a username and a password to in order to get a security token. As described in WS-Security. By default username and password are similar to management console user name and password which are “admin”,”admin”).
Add all user groups from the next window and click finish.
Running the Requester
But.. wait.. Where is the service? Here we can run the STS client without setting the relying party in IS in order to grant a security token. It is not necessary to have a relying party to grant the security token from the STS.
The client code is written to send RSTs to a given end point defined at src/main/resources/client.properties
is the service URL of the STS if you have started the IS on default port.
Without changing other properties you can safely run the client via shell script located at sts-client folder via
command. It will print the received SAML assertion on the terminal. You also can view the RST and RSTR on the SOAP tracer of the management console of Identity server.
Changing the Client Properties
Client configuration can be changed using the client.properties file which is located at dir src/main/resources
Quick look at the property file
You can change the relying party address (which we didn’t use here) from here. Here end point URL of the WSO2 ESB echo service has been given.
SAML version of the RST can be changed from here. (Depending on the version, SAML assertion issued from the STS will be changed)
Username and password for UsernameToken security policy