One of the neatest things about the standard Vordel evaluation/training VM is that it ships with an mashup of the SalesForce API with CDYNE’s EmailVerify API. This example Vordel Gateway circuit is run from a simple Web form, which is shown below. It is based on a scenario where an organization has an existing internal CRM, and they want to broker the data out to SalesForce.
Once the Web form is submitted, it hits maps to a circuit on the Vordel Gateway which first calls out to the EmailVerify API to verify that the email address in the form is valid.
So, here is the form which is submitted. I’ve entered info for a user called “Joe Demo” here in Boston. Note that I had to give him a valid email address (my own email address!) because the EmailVerify API really does validate the email address and so “joe.demo@example.com” would be blocked.
In the Real-Time Monitoring on the Vordel Gateway, we see the API calls out to the SalesForce login service (to get a SalesForce Session which the Gateway then caches), the EmailVerify API, and SalesForce’s API itself, which we use to register the data from the form as a new lead in SalesForce.
And, sure enough, “Joe Demo” is now in SalesForce:
How does this work? If we look at the circuit in the Vordel Policy Studio, we see that the mashup of the EmailVerify API with the SalesForce API is done using simple “drag-and-join” configuration. No coding is required. As well as connecting to the two APIs, we are also enforcing an SLA over the connection to SalesForce, as you can see. Notice also how we are caching the SalesForce SessionID.
An interesting aspect of the SalesForce integration is the protection of the API keys used to access SalesForce. Notice how the Vordel Gateway encrypts all of the SalesForce credentials, as shown below. Vordel is a member of the Cloud Security Alliance and has provided guidance on the CSA blog about protection of API Keys. This is how we do it in the Vordel Gateway:
If you want to get your hands on this demo yourself, and experiment with brokering and mashing up SalesForce and other APIs, contact us.
Enabling OAuth To A Google JSON API Using The Vordel API Gateway
OAuth is a very popular way to manage access to APIs. Amongst other things, it enables users to log into an application (which could be an application on a phone or tablet) and then that application calls lightweight APIs on their behalf. From a user’s point of view, they accessed the application, and it all “just worked”. They didn’t have to enter any more passwords. From an implementation perspective, it’s more complex of course. But an API Gateway makes it simple to call lightweight APIs using OAuth.
When I say “Lightweight APIs” in the paragraph above, I mean REST Web Services which generally use JSON. And what is JSON? JSON is a lightweight alternative to XML, which is increasingly used to bypass heavyweight XML parsing (and, in some cases, to bypass the security controls of the XMLHttpRequest object often used in AJAX).
JSON and REST can be seen as more efficient optimizations of what went before. OAuth is far from being “just another authentication mechanism”. To understand OAuth involves understanding how it is used. For APIs, it generally involves an application (e.g. an Android app) accessing the API on the user’s behalf. Phil Hunt has an excellent explanation of this aspect of OAuth here:
OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner’s (e.g. the user) behalf using only HTTP to access REST based services in a lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified “scope”.
[ It's also worth following the link above to Phil Hunt's piece if you're ever wondered why the HTTP header "Authorization" is not called "Authentication"]
So, all in all, there are a lot of new technologies at play here: OAuth, JSON, APIs, and even REST. And there is also a new concept, the API Gateway. An API Gateway applies the security mechanisms such as OAuth, which is required to authenticate to an API. But, beyond this, it also provides:
Monitoring of the API usage
Alerting if the API is not responding correctly
An audit trail of API access
Validation of API content
Redaction and tokenization of content being sent in API calls
Mapping to identity stores
Putting it all together, here is a demo of how a user can authorize the Vordel API Gateway to access a JSON API with OAuth on their behalf.
In the video below, I’m using an Android tablet to authorize the Vordel API Gateway to access an API on my behalf. In the Android environment, I am already logged in with Google, and the API Gateway leverages this to ask me do I want to access the API using my Google logon. In this case the API is a Google URL-shortening API. When I authorize it, then from that point on the Vordel API Gateway is enabled to access this API on my behalf. At the API Gateway level, you can see in the video that the API usage and access is managed. The API Gateway administrator can add controls such as JSON validation, detection of private data leakage, and tokenization (replacement of private data with an opaque token). At no point does the user have to worry about creating OAuth headers – this is all taken care of at the API Gateway.
This is the first in a series of videos on the API Gateway topic – watch this space for more!
An often-overlooked aspect of security is the Audit Trail. In the case of a REST API, we want to know not only that a REST API call was blocked, but why it was blocked.
Let’s take a look at the Real-Time Monitoring from the Vordel Gateway, deployed to manage a REST API. We see the orange spike indicating that an API call was blocked:
The key to looking up the Audit Trail is the message ID. Vordel users will be familiar with this ID as the ${id} attribute which is automatically created for each message in the Gateway. In this case, I highlight the message ID for the offending message and copy it:
Then I tab over to the Audit Trail and paste the Message ID into the search form:
When I press the Search button, I can see the message content, including the SQL Injection attempt which I have circled. The Vordel Gateway detected and blocked this attack against the REST API.
So, it’s important to know not only that a REST API call was blocked, but why it was blocked and what the REST API call actually was. This is the value of an audit trail. In addition, the Audit Trail logs may be signed, and the key used to sign them may be stored on a HSM (Hardware Security Module). All of the screenshots were taken from the Vordel evaluation image, which you can request more from info@vordel.com
A very common question asked by Vordel Gateway users is “How do I call out to an API or Web Service from within the Gateway, then use the response in a request to another destination?”. I notice that people often gravitate to the “Web Service Filter” or “Call Internal Service” filter for this, but that’s not actually how it’s done.
The way to do this is to use the “Connect to URL” filter. In the example below, I am calling out to a REST API from within a circuit on the Vordel Gateway. You can see that because the initial request to the Gateway is a POST (it’s a SOAP message coming in) and the call out to the REST API is a GET, I’m using a “Set HTTP Verb” to set the verb to “GET” before making the request to the REST API (a REST STS in this case, to request a SAML Assertion). I then am taking the response from that service, and using it in the construction of a request to the destination Web Service, which is an SP (Service Provider) that expects a SAML Assertion to be sent to it.
It’s quite easy, in this way, to string together many calls to different APIs or Web Services.
Note that if you want to store the initial request, make the callout “off to the side” to another service, then restore the initial request (i.e. not overwrite it with the response from the service you called “off to the side”) then that’s where the “Store” and “Restore” filters are used.
Bridging the gap between old and new is a challenge we all have been grappling with forever. It’s inevitable that the “IT” thing of today, will be replaced by a new innovation down the road. The caveman started with the rock, which was later replaced by the club, which later gave way to the spear. New advancements did not replace the previous technology entirely; rather it simply redefined more appropriate uses. For example, stones are ideal to craft spear points, and clubs when laced with leather and curved stones proved invaluable for digging. Thankfully, this innovation continues to propel society forwards, but it often leads to confusion for “traditionalists” who find themselves unwilling to adopt or change. So, what does all this have to do with technology? Plenty, read more to find out why.
