Monday, December 17, 2012

Going beyond simple authorization - taking context into account

Patrice Goutin from Oracle has written a useful guide to taking context into account for authorization decisions made with Oracle Enterprise Gateway (OEG) and Oracle Entitlements Server (OES). He uses the example of an art gallery which takes each employee's experience into account when allowing them to handle certain paintings. This goes beyond a simple authorization rule ("this employee can do this, this other employee can do that") or even Role-Based Access Control (where you'd have to assign employees to roles). Context is important. Other examples of contextual decisions, which you can also implement using OEG and OES, include controlling access to services based on where a client connects from, or what device they are using.

Sunday, December 9, 2012

Job posting: Network Engineer - Security, based in Phoenix

Volt Technical Resources is searching for a Network Engineer - Security, to be based in Phoenix. Skills required include experience with Vordel products:

Technical design proficiency with their current infrastructure would be a huge plus, and would include experience with: Juniper, CISCO, IBM, HP, F5, NetApp, VMWare,Vordel, Safenet, TippingPoint, PAN(Palo Alto Networks);

Saturday, December 8, 2012

Of Blacklists and Whitelists

The Vordel API Server ships with many samples, and one of them is a sample policy which scans XML content for threats. It includes a Threatening Content check as one of the filters used. You can see it in the screenshot below (it's the third item in the circuit):

If we double-click on the Threatening Content filter, we can see that it is using a list of attacks, including SQL injection, DTD attacks (e.g. XML Element Expansion), etc.

This is a blacklisting approach. We're checking if any of the content is on the blacklist. But often it makes sense to do whitelisting. This involves a strict check that the content is valid, so that any invalid content (e.g. an attack such as SQL Injection or Cross-Site Scripting) will simply fail the check. Here's an example of a whitelisting policy I've configured in the Vordel API Server to scan SOAP body content. There are a number of simple steps. Firstly, I am  using XPath to read in the content of the XML elements into a string (called "ContentToScan"). I'm reading in the content of the elements under the SOAP operation.

Then, I'm using a "Validate Selector Expression" filter to validate this string. You can see below that I'm validating it using a regular expression which checks that the content of the XML elements contains only alphanumeric characters or a dash ('-').

In this way, any content which does not pass this validation rule will result in this filter returning false, and therefore going down the red line in the policy execution (as opposed to the green line if it's valid). You can see the policy execution graphically in the screenshot above.

You can also combine blacklisting with whitelisting, simply by combining the two in one policy on the Vordel API Server, or calling one policy from the other using a Policy Shortcut. That gives you the best of both worlds.

Blocking identity leakage: Why an organization should become an IdP

This week, my colleague Ed King presented a webinar with Eve Maler (@xmlgrrl) from Forrester about why organizations should become identity providers. This is an important topic. Organizations are leaking identity. The path of least resistance is for an employee to use a login, another SaaS service login, or even a Google Apps or Facebook login to log into a third-party site. The third-party site could be a B2B procurement hub, or a corporate travel service. In that case, the SaaS service becomes crucial as the IdP (Identity Provider) which enables the user to log into the service. This is undoubtably good for the SaaS service, which is why so many are becoming IdP by supporting standards such as OAuth 2.0 and SAML. But what about the organization itself? Would it not be better for the organization to to stop the identity leakage and become an IdP itself?

In the webinar, Ed and Eve talked about why organizations should become IdPs. But the next question is how. The Vordel API Server makes this easy.

OAuth 2.0 and SAML are two key standards used to become an IdP. They enable a token to be issued, based on a user's login. Let's look at OAuth 2.0 first:

OAuth 2.0

The Vordel API Server comes with a prebuilt OAuth 2.0 sample. In this sample, you can see a sample app asking the user to authorize a connection to a third-party service. In the example below, I've setup an organization to use the Vordel API server to act as an IdP by authenticating the user against a corporate Active Directory, and then to prompt the server to allow a third-party site to access their information.This results in user being issued an OAuth 2.0 Access Token, and the third-party site receiving an OAuth 2.0 bearer token.

Here is how I'm authenticating the user against a corporate Active Directory then redirecting them to the OAuth 2.0 services:

You can see an example of the bearer token below in the Vordel API Server traffic monitor:

And here's the policy on the API Server which validates the OAuth 2.0 bearer token:


Now let's look at the SAML use case. SAML is often used, in this content, to issue a signed SAML Authentication assertion for the IdP to assert that the user has been authenticated. The policy below, in the Vordel API Server, allows an organization to act as an IdP by authenticating a user against a corporate Active Directory and then issuing (and signing) a SAML Assertion:

Here is how the Active Directory connection is configured (note the long list of other identity connectors in the Vordel API Server):

Finally, here is the signed SAML Assertion which is issued by our IdP policy.

At this point, you may be thinking "What should I use for my IdP, SAML or OAuth 2.0?". Well, it usually isn't a case of either/or. A third-party provider may dictate the answer by only supporting one or the other. But in the example above, you can clearly see that an OAuth bearer token is a lot smaller than a signed SAML Assertion, and size may be a big consideration for mobile use cases. In any case, you can support both with the Vordel API Server, getting the best of both worlds.

So, to make the first step for your organization to become an IdP, download your copy of the Vordel API Server here.

Tuesday, December 4, 2012

Allowing (or disallowing) HTTP 1.1 for a Vordel API Gateway connection

The Vordel API Gateway makes it easy to allow or disallow HTTP 1.1 for connections to backend services. If you wish to allow HTTP 1.1, you create a Remote Host setting as shown below, making sure that the hostname and port exactly match the hostname and port used by your backend service. So, if you're using a "Connect to URL" filter, the hostname and port should be the same as what you put in the Remote Host.

Then, as you see below, you can choose to check the "Allow HTTP 1.1" checkbox if you wish to allow HTTP 1.1 for the connection. 

Note that this is for the downstream connection to a back-end service (e.g. an API which the API Gateway is calling), not for connections from clients to the API Server.