Friday, May 21, 2010

More SAML: Validating a SAML 2.0 Assertion

It's simple to setup the validation of a signed SAML 2.0 assertion in a Vordel XML Gateway. In a circuit, chain together (1) an "XML Signature Verification" filter (which you can find in the "Integrity" group on the right-hand-side of Policy Studio), and (2) a "SAML Authentication" filter (which you can find in the "Authentication" group).

With XML Signature Verification filter, make sure that the SAML assertion is selected under "What must be signed". In the filter to validate the SAML assertion, make sure that it's a SAML 2.0 assertion.

Really what we are doing here is first verifying the SAML assertion (i.e. checking it's trusted, using its signature) and then validating it (making sure it's the right format). By checking the trust first, we are ensuring that we are not wasting time validating an untrusted SAML assertion. It is important to understand the difference between verifying and validating a token like this. The configuration for the validation step is shown below:

To test this circuit, I am using the SOAPbox testing tool.

We see on the Response screen of SOAPbox that the assertion we've sent is indeed valid. If you change its signature in any way, the Vordel Gateway will reject it. Grab an evaluation of the Vordel Gateway here.

Wednesday, May 19, 2010

How to insert attributes into a SAML Assertion

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

A frequent use of the Vordel XML Gateway is to enrich messages on the network by inserting user attributes into them, formatted as attribute statements in SAML assertions. Often, these attributes come from an LDAP directory.

There is an excellent guide on the Vordel Extranet for doing this - here: You need a username-and-password to get that doc (contact for one). But, to get you started, here are the simple steps to configure the Gateway to do this:

1) Authentication against the LDAP directory. As well as performing authentication, this populates the "Attributes for use in subsequent filters". These are what are used for looking up attributes.

2) Look up attributes from the LDAP directory using a "Retrieve from Directory Server" filter. This is where attributes like "location", "role", etc are looked up. The Distinguished Name (or whatever was set in Step 1) is used as the look-up key to find the attributes.

3) Insert a SAML Authentication Assertion including all of the Attributes in an included Attribute Statement. This is straightforward to configure but you have to remember to put "Insert SAML Attribute Statement" in the "Advanced" tab.

4) (optional) Use an "XML Signature Generation" filter (from the Integrity group) to sign the assertion. It's best to sign the assertion with an enveloped signature (which you can do by choosing the XPath to insert the XML Signature into the SAML Assertion) because that means that when the SAML assertion is taken and put into another message, it is still signed and the signature can be verified.

After configuring each step, put a "Reflect message and attributes" filter at the end of the circuit and then you can see the various attributes on the Vordel Gateway's "whiteboard".

That's all you need to do to configure a circuit in the Vordel Gateway to authenticate a user, retrieve user attributes from an LDAP directory, and then insert them into a (signed) SAML assertion.

Monday, May 10, 2010

Using Oracle Access Manager with Vordel to manage SOA and Cloud usage

Recently I was setting up the Vordel Gateway with Oracle Access Manager in order to insert OAM session tokens into SOAP messages. For anyone setting this up, I highly recommend the Vordel Oracle Access Manager Integration Guide, which walks through the setup process. It's available on the Vordel Extranet (login required - contact for details).

The combination of Gateway technology with SSO products is very powerful. But, perhaps even more important, is the fact that Cloud Service Brokers can leverage the tokens issued by SSO products, and make use of an STS (Security Token Service) in order to map them to the tokens understood by cloud providers. This addresses the "Costanza's Wallet" problem, i.e. the proliferation of multiple token types, both within the organization (Kerberos, SSO tokens such as Oracle Access Manager and CA SiteMinder) and Cloud-side (Oauth, OpenID). Cloud Service Brokers are vital for keeping this "golden thread" of identity right from within the organization up to the Cloud-based properties used by that organization. This allows for a reliable audit trail.

Saturday, May 8, 2010

Vordel en francais

Vordel has run its inaugural French language user group in Paris - read all about it in French here.

Tuesday, May 4, 2010

On Cloud Security's "PR Problem"

David Linthicum reports on Cloud Security's PR problem, quoting a Harris poll that:
"One of the main issues people have with cloud computing is security. Four in five online Americans (81 percent) agree that they are concerned about securing the service. Only one-quarter (25 percent) say they would trust this service for files with personal information, while three in five (62 percent) would not. Over half (58 perent) disagree with the concept that files stored online are safer than files stored locally on a hard drive and 57 percent of online Americans would not trust that their files are safe online."
He concludes that:
"There is no easy answer to this problem, though a look to history can help. When the Web first hit businesses, it was feared and misunderstood until the business value became clear to all. This took years, and even today we use the traditional Web by taking the good (for example, the ability to find instantly the one piece of information that caps your presentation to the board) with the bad (the creepy guy down the hall who was caught surfing porn). The benefits outweigh the problems, and cloud computing will eventually find a similar path to acceptance.",1
It is indeed useful to "look to history" here. Back in the early days of the Web, there was a lot of concern about sending private data over the web. People did not trust the public internet with their private data, and certainly not with credit card numbers. But was this a "PR Problem"? Not really, since the fears were justified. Users and organizations decided that the private data could never travel over the public Internet in the clear. So, it wasn't a case that users did not trust the public Internet with their data and now they do, but that they learned to put a mitigation in place which would allow them never to trust the public Internet but still use it for commerce.

So, with Cloud service providers, the logic is that customers should be able to put mitigation in place which would allow them to never to trust the Cloud provider with their private data. Even though vendors like Amazon and Google may be widely trusted, trusting them with your private data is another matter. It may never be possible for some users to allow Amazon or Google to store their private data, however trusted they are, simply because they are a third-party.

These mitigation strategies include selectively encrypting private data before it is sent up to the Cloud provider, and scanning traffic to the Cloud provider for privacy breaches. This is similar in principle to how SSL encrypts the private data before it is sent over the public Internet. The task is not to solve Cloud computing's security PR problem, but instead to allow it to be used in a trusted manner. The key to this is the Cloud Service Broker, which brokers the connection to Cloud services and applies trust by selectively encrypting and scanning the data sent up to the Cloud provider.