Thursday, September 29, 2011

Automated API testing

If you download the free SOAPbox testing tool, you may not realize that (a) you can use it to test REST APIs, and (b) this testing can be automated.

SOAPbox comes with a command-line tool called sr (Service Request) which will automate requests to an API or Web Service. Here is how you can use it to call the healthcheck API on the Vordel Gateway, when the Gateway is running on the same machine:

sr -v GET -h localhost -u/healthcheck -s 8080 -p10 -d10

The "-p 10" means to run ten parallel threads. "-d 10" means to run for ten seconds.

Definitely a very useful tool to simulate and test API access.

Tuesday, September 27, 2011

Issuing a SAML Assertion with a simple STS on the Vordel Gateway

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

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.

Monday, September 26, 2011

Authentication using custom tokens with the Vordel Gateway

Although standards like WS-Security exist, it's a fact of life that many organizations use custom authentication tokens to authenticate clients. This happens for a variety of reasons, such as the fact that WS-Security presupposes the usage of SOAP, and that just isn't an option for many people in the world of lightweight REST-based APIs.

Supporting custom authentication tokens is simple with the Vordel Gateway. It consists of two steps in Policy Studio:

1) Read in the username and password into two variables (called "attributes" in the Vordel Gateway).

If you want to read in a username from a HTTP header, for example, then drag in a "Retrieve from HTTP Header" filter, and type in the header name (e.g. "Username"), and then the attribute ID you want the value to be read into (e.g. "authentication.subject.id"). If you want the value to come from the Query-String (i.e. from the name-value pairs after the "?" in the URL), the check the box called "Use Query String Parameters".

If you want to read in a username from the message itself, use a "Retrieve from Message" filter, and then configure it with the XPath used to find the value. Tip: Save a copy of a message, then use the XPath Wizard (hit the little "magic wand" icon) to open it and tell the Gateway where your custom token is.

Then a similar procedure to read in the password from the message header (the "Retrieve from HTTP Header" filter) or message body (the "Retrieve from Message" filter). Usually I read this into the attribute "authentication.subject.password".

2) Drag in an "Attribute Authentication" filter (you can find this in the "Authentication" group) and chain it after the filters you setup before. In the example below, you can see that I've read the username and password into the attributes "authentication.subject.id" and "authentication.subject.password" respectively. I now ask the Gateway to validate these credentials.


Friday, September 23, 2011

Catch the Vordel and Forrester Webinar next week: The Expanding role of the Gateway in a Modern IT Architecture

Randy Heffner, Forrester analyst, and Vordel are presenting a webinar next Thursday at 11am Eastern on "The Expanding role of the Gateway in a Modern IT Architecture". It's a good chance to see how APIs and the Cloud are changing the game, and how Gateways apply now more than ever.

Attendees will learn how to:
  • Deploy Enterprise Applications Beyond The Network Perimeter
  • Consume Cloud Services Without Losing Control or Compromising Security
  • Secure All Application Connections Using Enterprise Security Infrastructure
Here is the free registration page.

Thursday, September 22, 2011

Free Vordel Workshop next month - Hotel Nikko, San Francisco - week of Oracle Open World

If you're in San Francisco for Oracle Open World next month, you can catch the wave, get your feet wet, and partake of other surfing metaphors at the free Vordel Workshop. This workshop will cover many Vordel tricks+tips, with a particular focus on Oracle interop. Here's the link to register, and here's the run-down:

Hands-on exercises and demonstration of using Vordel Application Gateway to:
  • Convert SOAP services to REST to enable mobile and Web 2.0 applications
  • Connect Cloud Applications to enterprise identity management for single sign-on
  • Leverage Oracle Access Manager to control access to Cloud based services
  • Enforce fine-grained authorization policies from Oracle Entitlements Server
  • Protect Oracle Service Bus from message level threats
  • Speed up your Oracle SOA applications by offloading XML processing and security tasks
  • Throttle service traffic and manage quota in real-time
  • Protect and audit Siebel's SOAP and REST service interfaces
Oh, and you get free stuff:
  • A free developer license to Vordel Application Gateway
  • Entry into a prize draw for a Pico Projector
  • A 16Gb USB 2.0 Hard drive
  • A limited edition Vordel Immerse T-shirt.

Wednesday, September 21, 2011

Content-based routing, with conversion for SOAP to REST, in the Vordel Gateway

The Vordel Gateway has some really neat features which make it very easy to do content-based routing based on parameters in a SOAP message, and to use these parameters to construct a REST request. Here is an example of how this is setup. First, I register the WSDL service (a Parlay-X AmountCharging Service) in the Web Service Repository in the Vordel Policy Studio, as shown below:



Next, in the policy which is called in the Gateway for this service, I drag in a "Retrieve attributes" filter. I the used the XPath wizard to open an example of the Parlay-X message, and I choose the "EndUserIdentifier" value by navigating to it. This is shown below:

What happens now is that the value from the endUserIdentifier XML element is read into an attibute called "EndUserIdentifier". I then follow this with a "Switch on Attribute Value" filter, to switch based on the content of this attribute. You can see in the circuit view below that I am switching on the attribute value after I read in the attribute value:


Here is a view of the "Switch on Attribute Value" filter. I am looking at the value of the "EndUserIdentifier" value, and checking does it start with certain values. In this case, I am looking at the country code value from a phone number in this element.


Finally, I am placing the EndUserIdentifier into a REST request to be sent to a REST API (in this case, the GSMA API):

The API parameters are created in a "Create REST Request" filter, as shown below. This is a very convenient way to construct a REST API request in the Vordel Gateway. As you can see, the EndUserIdentifier is being populated dynamically:


I then use Vordel SOAPbox (free download) to test this, by sending messages to the SOAP service:

In the Real-Time Monitoring of the Vordel Gateway, you can see the Gateway is now dynamically reading the value of the EndUserIdentifier element:


Contact info@vordel.com to get a copy of the Vordel Gateway to test this out for yourself...

Friday, September 16, 2011

How to authenticate then issue a SAML assertion in the Vordel Gateway

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

Issuing a SAML assertion into a message with the Vordel Gateway is quite straightforward. If you follow an authentication filter with an "Insert SAML Authentication Assertion" filter, then a SAML assertion will be placed into the message after you've authenticated the client. Then, to call the target Web Service, you can use a "Connect to URL" filter, which results in the Gateway calling the target Web Service, with the client message which now includes the SAML assertion.


What about putting SAML attributes in that assertion? If you have authenticated the client against SiteMinder or Oracle Access Manager, for example, then you can check the "Insert SAML Attribute Statement" checkbox on the "advanced" tab of the SAML filter, and it results in the Gateway inserting in the SiteMinder smsession, or the Oracle obsso token, into an attribute statement in the SAML assertion.

Below you can see an example of a message sent into the Vordel Gateway, and following that you see the message after the SAML assertion has been inserted:


<soapenv:envelope soapenv="http://schemas.xmlsoap.org/soap/envelope/" tem="http://tempuri.org/">
<soapenv:header>
<soapenv:body>
<tem:getdata>
<tem:value>123</tem:value>
</tem:getdata>
</soapenv:body>
</soapenv:header></soapenv:envelope>

<!--?xml version="1.0" encoding="utf-8"?-->
<soapenv:envelope soapenv="http://schemas.xmlsoap.org/soap/envelope/" tem="http://tempuri.org/">
<soapenv:header>
<wsse:security wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:assertion saml="urn:oasis:names:tc:SAML:2.0:assertion" id="Id-0001316150618498-71f75ed54e72dd5a12116c6c-2" issueinstant="2011-09-16T05:23:38Z" version="2.0">
<saml:issuer format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
MyCompany
</saml:issuer>
<saml:subject>
<saml:nameid format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
demo
</saml:nameid>
<saml:subjectconfirmation method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">
</saml:subjectconfirmation></saml:subject>
<saml:conditions notbefore="2011-09-16T05:23:37Z" notonorafter="2011-09-16T05:28:37Z">
<saml:authnstatement authninstant="2011-09-16T05:23:38Z">
<saml:authncontext>
<saml:authncontextclassref>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:authncontextclassref>
</saml:authncontext>
</saml:authnstatement>
</saml:conditions></saml:assertion>
</wsse:security>
</soapenv:header>
<soapenv:body>
<tem:getdata>
<tem:value>123</tem:value>
</tem:getdata>
</soapenv:body>
</soapenv:envelope>
How does this relate to an STS (Security Token Service)? The answer is that you can certainly see the issuance of that SAML assertion in the Vordel Gateway as an example of a security token being issued. Do you need to call out to an STS to do this? No. In this case the Gateway itself is issuing the SAML assertion, without any needs for callouts to anywhere.

Monday, September 12, 2011

You know you're a geek when...

You know you're a geek when the rental car company offers you a free upgrade to the 2012 Ford Mustang, and you agree primarily because you know it comes with a handy USB charger in the center console...

[You also know you're a Droid user when you're constantly on the lookout for ways to keep your phone charged].

Saturday, September 3, 2011

Speaking at Oracle Open World - Tuesday October 4th in San Francisco

It's not often I am on the same roster as Sting and Tom Petty, but at Oracle Open World I am. Admittedly Sting and Tom Petty will be performing to tens of thousands of people on Treasure Island, whereas I will be speaking at the much less dramatic setting of a Moscone Center auditorium the previous day.

My presentation is titled "Cloud Security Case Studies of SaaS, PaaS, and IaaS". The talk comes under the "Focus on Identity Management" list talks, and on that list I see a whole bunch of talks which I hope I will have the opportunity to attend. The conference is always very busy with many customers present, so that may be difficult, but I will try.

If you're going to be at OOW, please let me know, and I hope to see you there!

Friday, September 2, 2011

CRLs and browsers, and how a Gateway can help

Zack Epstein reports on the DigiNotar certificate breach, noting that:
The compromised certificates have all revoked by DigiNotar, but not all Web browsers check for revoked certificates so the impact of this breach will likely be ongoing for some time.
http://www.bgr.com/2011/09/01/ssl-certificate-breach-extends-beyond-google-over-200-certificates-compromised/
It is an understatement to say that "not all Web browsers check for revoked certificates". Very few do. If you're using Firefox, take a look at Tools -> Options, then under the Advanced tab (not the "Security" tab as you might expect) click on "Revocation Lists". How many Certification Revocation Lists (CRLs) are listed there? Zero, right? Hint: You can add some CRLs from Verisign by clicking on the links on this page: http://www.verisign.com/repository/crl.html

Newly minted browser versions have the problematic certs removed from their trust lists. But, if browser manufacturers made it easier for people to use CRLs by default in their browsers, then that would not matter.

But are people really likely to manually add these CRLs? Probably not. Users should not have to know about the difference between the root certificate trust list in the browser, and a CRL. All of this conspires to make security hard for users.

A Gateway can help. When web traffic passes through a Gateway, it can check the CRL lists, and disallow traffic to a host using a revoked certificate. In the Vordel Gateway, configuring CRL checking is a matter of dragging-and-dropping CRL filter onto the canvas of a default policy. Now it checks the SSL certs against the CRLs, without changing anything on your users browsers. With the current situation where setting up CRL checking in a browser is not there by default, and way more complex than it needs to be, a Gateway is a pragmatic solution to address this problem.