Signed SAML tokens are often used to propagate identity information in an API request. Although we're increasingly people using OAuth with the Vordel Gateway, SAML remains the established technology and is not going away anytime soon. Here is an overview of how you can create a signed SAML Assertion at the IdP (Identity Provider) then send this in an API request to a SP (Service Provider). As an extra architectural detail, I am issuing the SAML Assertion using a REST STS interface.
You'll notice below that I'm using the
snazzy new Vordel 6.2 release, because of the new re-arranged search interface on the right, and the new "libraries" (blacklists, whitelists, etc) and "resources" (scripts, schemas, stylesheets, etc) groups on the left.
Here is the IdP policy. It's very simple. I am firstly authenticating the browser client, then calling out to a REST STS to request a signed SAML Assertion for the user. I'm the validating the signature on the SAML assertion.
That request to the REST STS? If I hit it directly with a browser, it looks like this:
Notice the response is signed and the digital signature is inside the SAML assertion. This means that the XPath used to validate the signature must not take the signature itself into account. The XPath for this is: (//saml:Assertion)/descendant-or-self::node()[not(ancestor-or-self::dsig:Signature)] . This is one of the example XPaths provided with the Vordel Gateway.
Now, I am placing the signed SAML Assertion into a form variable called SAMLResponse, as shown below. This is what I am sending to the Service Provider (SP):
<form method="post" action="http://sp.example.org:8080/SAML2/POST" ...>
<input type="hidden" name="SAMLResponse" value="PHNhbWw6QXNzZXJ0aW9uIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDph
(truncated)
Pg==" />
<input type="submit" value="Connect to Service Provider"/>
</form>
At the Service Provider, I Base64-decode the SAML Assertion in the Vordel Gateway, check its signature and the trust of its issuer, and then return the response from my service. I can see all this happening in the Traffic Monitor of the Vordel Gateway. I see the IdP service, the REST STS, and the Service Provider.
I double-click on any of the services, I see the tracking of what happened step-by-step inside the policy. You'll notice that the steps here map to the steps in the first screenshot above. The Traffic Monitor shows the time for each step also, as it runs on my laptop.
So that shows how you can setup an IdP, SP, and REST STS all on the Vordel Gateway. Now, normally you would not be running all these components on the same machine. But it's certainly a useful exercise to learn about how it all works.-->
