Many different token formats are used in the world of SOA and Cloud. These include OAuth, UsernameTokens, X.509 Certificates, Kerberos tickets, and custom tokens such as the SiteMinder smsession. All these token types can cause confusion, and also introduce complexity if applications are expected to support them all.
To deal with this issue, it's a common practice to convert these tokens into a common token type. And, often, this is SAML. How it works is that, following validation, a SAML assertion issued which
asserts that the token was validated. This means that the token itself no longer needs to be sent with the message. It also means that the recipient system only needs to understand SAML.
The piece of infrastructure which converts tokens is called a
Security Token Service. Gunnar Peterson, in his
Security Architecture for the Cloud, includes an STS as well as a Gateway as core components. In the case of the Vordel Gateway, a logical STS can be implemented with the Gateway. Let's look at how this is done...
We'll focus on a common scenario in the field: How a SAML Assertion is in response to a Username Token. The policy below, configured in the
Vordel Gateway, takes in a UsernameToken, validates it, and issues a SAML Assertion in response.
Let's look at the chain of filters which are used to achieve this. Starting from the top in the screenshot above, we see:
Register Security Token Service for Monitoring. This is a "Set Service Name" filter, from the "Monitoring" group in Policy Studio, which I've configured to set the service name as "Security Token Service". Once this name is set, the service is visible in the "services" table of the Gateway's Real-Time Monitoring, as well as in any product which is monitoring the Gateway (e.g. Oracle Enterprise Manager).
Validate WS-Security UsernameToken. This is a "WS-Security UsernameToken" filter, from the "Authentication" group of Policy Studio. I've configured this to authenticate a user against the Local User Store in the Gateway, for simplicity.
Process STS Request. This is an "STS Web Service" filter, from the "Security Services" group in Policy Studio. This filter processes the incoming RST (Request Security Token) message, and constructs the "scaffolding" of the RSTR (Request Security Token Response) for us to place the SAML assertion into.
Insert SAML Authentication Assertion. This is an "Insert SAML Authentication Assertion" filter, from the "Authentication" group in Policy Studio. It inserts a SAML Assertion, and the NameIdentifier it places into the SAML assertion is taken from the username in the WS-Security UsernameToken (specifically, it comes from the authentication.subject.id attribute). Note that if you wanted to place a different name in the SAML Assertion, you could, for example, read the value from the message using a "Retrieve from Message" filter and then configure that filter to write the value into the authentication.subject.id attribute.
XML Signature Generation. This is an "XML Signature Generation", taken from the "Integrity" group in Policy Studio. I've configured it, under the "What to Sign" tab, to sign the SAML Assertion using the pre-built XPath for this purpose. Under "Where to place signature", I've chosen to place it into the WS-Security header for "Current actor/role only".
Return STS response. This is simply a "Reflect" filter, from the "Utility" group in Policy Studio. I am using this to return a 200 response code to the client.
So let's see this STS policy in action....
Here is an example message, which you can see is an RST (Request Security Token):
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-00000132a9381221-0000000001a99295-4"><wsse:Username>Joe User</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">vordel</wsse:Password><wsu:Created>2011-09-27T04:50:16Z</wsu:Created></wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body><wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"><wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType><wst:TokenType>SAML</wst:TokenType></wst:RequestSecurityToken></soap:Body>
</soap:Envelope>
I've wired a path in the Gateway so that requests to the path /STS-Example hit this policy:
So, next I use
the free SOAPbox testing tool to send a request to this policy. As you can see below, I have loaded in my request on the left-hand side. I actually created the UsernameToken using the "Insert WS-Security UsernameToken" option under the "Security" menu. [Note that if you're inserting a UsernameToken to replace an existing one in the message, you must delete the existing one first]. I configured the UsernameToken as shown:
Then I pressed the little green "play" button on the toolbar to send my request.
You can see on the right that the response back to me is a signed SAML Assertion. That's all that's involved in creating a simple STS with the Vordel Gateway.
