How to Read in a SAML Assertion from a REST STS and Insert it Into a HTTP Header
Join the DZone community and get the full member experience.
Join For FreeIt is a common scenario that an API Server must call out to a Security
Token Service (STS) "off to the side" in order to get a SAML assertion
issued for a user. This SAML Assertion then then usually inserted into
the request, often as a HTTP header. Let's see how this is done with the
Axway/Vordel API Server...
Firstly, I've setup an STS policy which is a "REST STS" (or "RESTS" for
short). It takes in a UserID as a REST parameter and issues a SAML
Assertion for that user. Here is the RESTS policy for this, below. Note
that it's being served from the same API Server instance, but it could
be served from another instance, or another product altogether could be
issuing the SAML Assertion:
Looking at the policy above, we see the steps are:
1) Use the "Extract REST Request Attributes" filter to extract the attributes from the REST request. These attributes are the parameters being passed as part of the REST request.
2) We copy the "userid" parameter from the REST request into the "authentication.subject.id" parameter, and also populate the other two parameters which are needed for the "Insert SAML Authentication Assertion" filter we will be using later in the policy. The filter now looks like this:
3) We use a simple "Set Message" filter to create a SOAP wrapper into which we will put our SAML Assertion. This looks like this:
4) We then insert out SAML Assertion, and I put "REST STS" as the issuer name. I also choose "Sender Vouches" as the Subject Confirmation Method.
5) Finally I round out the policy with a "Reflect Message" to return the SAML Assertion back to the client.
So next, let's look at the policy which calls this REST STS. Here's a screenshot of it in Policy Studio:
At a high level, this policy is firstly authenticating the client, then it is calling out to an STS to get a SAML Assertion for the client, then it is inserting that SAML Assertion into a HTTP Header. Note the Store and Restore filters which are used. These are used if you want to store the incoming message before calling out to the STS, because the message will be overwritten by the response from the STS. Note that if you're receiving a HTTP GET request initially, you don't need to use Store and Restore, simply because there is no message to store and restore.
${authentication.subject.id} parameter as a parameter to my REST STS:
If we had been calling a more traditional WS-Trust STS, I would have used a "Set Message" to create the RequestSecurityToken message, then used a "Set HTTP Verb" filter to set the verb to "POST", then a "Connect to URL" filter to connect to the STS.
5) Restore Message. This is restoring the original message (which was over-written by the response from the STS, when we called out to the STS "off to the side").
Published at DZone with permission of Mark O'Neill, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
What to Pay Attention to as Automation Upends the Developer Experience
-
Turbocharge Ab Initio ETL Pipelines: Simple Tweaks for Maximum Performance Boost
-
TDD vs. BDD: Choosing The Suitable Framework
-
Adding Mermaid Diagrams to Markdown Documents
Comments