Renewing received SAML bearer type tokens

My last blog post described how to receive SAML 2.0 tokens with Identity Server. Token that are received can be expired as defined in

[xml]<wsu:Created>2014-08-19T09:41:55.832Z</wsu:Created>
<wsu:Expires>2014-08-19T09:46:55.832Z</wsu:Expires>[/xml]

attribute. Therefore the client has to update the received token. This blog post will define how to renew the received bearer type SAML 2.0 token using the WSO2 identity server’s resided token service.

After the security token service is configured you can run this client as the token renewer.

Running the Client

This client supports command line arguments to select the SAML Version and send token renew requests.

In the configuration file, you can enable the renew property to send renew requests to the server.

[shell]enable.renew=true[/shell]

Also, you can specify SAML version on the command line. For SAML version 2.0,

[shell]sh sts-client.sh samlVersion 2.0[/shell]

For SAML 1.1,

[shell]sh sts-client.sh samlVersion 1.1[/shell]

As an example,If you want to send a request for a SAML 2.0 security token, then to renew it and validate the renewed token you can do following configurations.

[shell]enable.binding.validate=true
enable.renew=true[/shell]

Then run,

[shell]sh sts-client.sh samlVersion 2.0[/shell]

You can see the original SAML assertion and the renewed assertion printed on the console.

Here is the response for SAML 2.0 security token request and a renewal response.

Initial SAML Assertion

[xml]<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema&quot; ID="urn:uuid:6E835985EF7F8C729E1412054251018" IssueInstant="2014-09-30T05:17:31.016Z" Version="2.0"><saml2:Issuer>localhost</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot; />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot; />
<ds:Reference URI="#urn:uuid:6E835985EF7F8C729E1412054251018">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature&quot; />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#&quot; PrefixList="xs" /></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1&quot; />
<ds:DigestValue>15wzu6K5Mk1Ffwvxx67MP0k2sDU=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
LaXHKhd8SFGGvBnNoICaSAlwRxxzZMQD5zjqtQ3quAY7fogVJo5QHBJwDLI8k2zl6X0s6z/PWcJx
20CZ+UrJZjnbp0mslVl3iM7U7SWD5bSPkrlPwFgiXh6CO/qmdfCPnBNdNGqgZPCQX4o6AR4+ohox
zxp7hJm+RhpMZhHj8Tk=
</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UE
CAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">admin</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" /></saml2:Subject><saml2:Conditions NotBefore="2014-09-30T05:17:31.016Z" NotOnOrAfter="2014-09-30T05:22:31.016Z"><saml2:AudienceRestriction><saml2:Audience>https://localhost:10443/services/echo</saml2:Audience></saml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2014-09-30T05:17:31.016Z"><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="http://wso2.org/claims/emailaddress&quot; NameFormat="http://wso2.org/claims/emailaddress"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">admin@wso2.com</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://wso2.org/claims/givenname&quot; NameFormat="http://wso2.org/claims/givenname"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">admin</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
[/xml]

Renewed Assertion

[xml]<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema&quot; ID="urn:uuid:6E835985EF7F8C729E1412054251018" IssueInstant="2014-09-30T05:17:31.016Z" Version="2.0"><saml2:Issuer>localhost</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#&quot; />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot; />
<ds:Reference URI="#urn:uuid:6E835985EF7F8C729E1412054251018">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature&quot; />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#&quot; PrefixList="xs" /></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1&quot; />
<ds:DigestValue>S2GS5Q2WFl4i2FupmZr+F8g8tfo=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
CUwxOhZDFQ0NdQiHz0gMBl0hsLn6eYegxSdQ+TjrsvMwrlacnSnRRT+1uMX5vCStgtm9bkI5dweS
Z1fZX3WGka0N7MHbly98H4a/2fpZIJari++/RVa68or3O80SwoJqIdnKwt1q5xPBhndpzgXEp3J7
hBPYVH4IsZYnaPpdfNk=
</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UE
CAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">admin</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" /></saml2:Subject><saml2:Conditions NotBefore="2014-09-30T05:17:31.439Z" NotOnOrAfter="2014-09-30T05:22:31.439Z" /><saml2:AuthnStatement AuthnInstant="2014-09-30T05:17:31.016Z"><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="http://wso2.org/claims/emailaddress&quot; NameFormat="http://wso2.org/claims/emailaddress"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">admin@wso2.com</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://wso2.org/claims/givenname&quot; NameFormat="http://wso2.org/claims/givenname"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:type="xs:string">admin</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
[/xml]
Also, if the renewed token has been validated you can see,

[shell]Renewed SAML 2.0 Token is valid[/shell]

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]