Request for SAML tokens with WSO2-STS

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.

[xml]<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">%5B/xml%5D

  • 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.

[xml]<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">%5B/xml%5D

  • Claim – A statement made about something. ie : <email>client@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

image002

The communication paths are showed by arrows.

  1. requester may grant a security token by sending a RST to the STS or from a third party.
  2. Then the token is submitted to the relying party to access it’s services.
  3. 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).

Simulation

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.

Workspace 1_019

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.

Download the client from here.

The client code is written to send RSTs to a given end point defined at src/main/resources/client.properties
By default

[plain]https://localhost:9443/services/wso2carbon-sts[/plain]

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

[plain]sh sts-client.sh[/plain]

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.

[plain]address.relyingParty=http://localhost:8281/services/echo[/plain]

SAML version of the RST can be changed from here. (Depending on the version, SAML assertion issued from the STS will be changed)

[plain]saml.token.type=2.0[/plain]

Username and password for UsernameToken security policy

[plain]
ut.username=admin
ut.password=admin[/plain]

 

5 thoughts on “Request for SAML tokens with WSO2-STS

  1. Hi, your blog seems to be very useful, but when I set enable.relyingParty=true then I get org.apache.axis2.AxisFault: Transport error: 401 Error: Unauthorized. When I set enable.renew=true then I get Renewing 2.0 java.lang.RuntimeException: Undefined ‘errorInRenewingToken’ resource property. When I do Validate SAML Request with generated assertion in Identity server I got Unable to unmarshal the request. When I use generated assertion in SOAP message +signature from generated assertion I got org.apache.xml.security.signature.MissingResourceFailureException: The Reference for URI #urn:uuid:88DC8669F96F62ABE61416303437666 has no XMLSignatureInput Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Id not found. What is wrong?

    Like

    1. Hi edo_nick, This renewal is a new feature and It might not have released yet, please get this rampart release and add the rampart/core and rampart/trust as patches in your repositories/components/patches
      http://wso2.org/svn/browse/wso2/carbon/platform/branches/turing/dependencies/rampart/1.6.1-wso2v13/modules/
      rampart-trust should definetly solve your renewal issue.
      About the 401 issue, I guess it is due to not adding the relying party in your relying parties section in the IS. please add your ws endpoint as a relying party brfore adding it in the properties file. Hope it will help..

      Like

      1. Hi, it looks so strange. I used libraries packed with client (rampart-trust-1.6.1-wso2v12.jar). So I don’t understand why it doesn’t work. I tried to check out modules but TortoiseSVN can’t do that because of “Redirect cycle detected for URL”. Is there jar instance?

        Like

  2. Hello, the post seems pretty interesting. I tried to configure all parties but not me BUS configuration is clear . What I should configure the service side ” echo” ? By adding security to service BUS it is not clear whether it would SAML or STS type . Thank you!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s