September 16th, 2011

OAuth Client Broker Tooling

In terms of OAuth enterprise tooling, a lot of focus is given to OAuth-enabling APIs exposed by the enterprise itself. Naturally, the demand for this reflects today’s reality where the enterprise is increasingly playing the role of an api provider. However, many enterprise integration use cases involving cloud-based services puts the enterprise in the role of API consumer, rather than provider. And as the number of enterprise applications consuming these external APIs grows, and the number of such external APIs themselves grows, point-to-point OAuth handshakes become problematic.

Another challenge relating to consuming these external APIs is that OAuth handshakes are geared towards a client application driven by a user. The protocol involves a redirection of that user to the API provider in order to authenticate and express authorization. Many enterprise integration (EI) applications do not function in this way. Instead their behavior follows a machine-to-machine transaction type; they operate at runtime without being driven by a user. Wouldn’t it be great if these EI apps could benefit from the OAuth capabilities of the APIs and still operate in headless mode? The so-called ‘two-legged’ OAuth pattern provides a work around for this challenge but requires the client app to hold resource owner credentials, which is problematic, especially when replicated across every client app.

To illustrate how an enterprise API management solution can help manage this challenge, I demonstrate an OAuth tooling geared towards brokering a client-side OAuth session with the Salesforce API using the Layer 7 Gateway. By proxying the Salesforce API at the perimeter using the Layer 7 Gateway, my EI apps do not have to worry about the API provider OAuth handshake. Instead, these EI apps can be authenticated and authorized locally using the Enterprise identity solution of choice and the Layer 7 Gateway manages the OAuth session on behalf of these applications. The benefits of this outbound API proxy are numerous. First, the OAuth handshake is completely abstracted out of the EI apps. In addition, the enterprise now has an easy way to manage control of which applications and enterprise identities can consume the external API, control of the rates of consumption and monitor usage over time. The API can itself be abstracted and the proxy can transform API calls at runtime to protect the consuming apps from version changes at the hosted API side.

To set this up on the Layer 7 Gateway, you first need to register a remote access to your Salesforce instance. Log into your Salesforce instance and navigate to Setup -> App Setup -> Develop -> Remote Access. From there, you define your remote access application. The callback URL must match the URL used by the Layer 7 Gateway administrator at setup time in the Layer 7 Gateway. Make sure you note the Consumer Key and Consumer Secret as they will be used during the OAuth handshake setup; these values will be used by your Layer 7 OAuth broker setup policy.

Using the Layer 7 Policy Manager, you publish your broker setup policies to manage the OAuth handshake between the Gateway and your Salesforce instance. Note that the OAuth callback handling must listen at a URL matching the URL defined in Salesforce. These policies use the consumer key and consumer secret associated with the registered remote access in your Salesforce instance. The secret should be stored in the Gateway’s secure password store for added security. Use templates from Layer 7 to simplify the process of setting up these policies.

Once these two policies are in place, you are ready to initiate the OAuth handshake between the Layer 7 Gateway and the Salesforce instance. Using your favorite browser, navigate to the entry point defined in the admin policy above. Click the ‘Reset Handshake’ button. This will redirect you to your Salesforce instance. If you do not have a session in place on this browser, you will be asked to authenticate to the instance, then you are asked to authorize the client app (in this case, your Layer 7 Gateway). Finally, you are redirected back to the Layer 7 Gateway admin policy which now shows the current OAuth handshake in place. The admin policy stores the OAuth access token so that it can be used by the api proxy at runtime.

Your Layer 7 Gateway is now ready to act as an OAuth broker for your EI apps consuming the Salesforce API. You can publish a simple policy to act as this proxy. This policy should authenticate and authorize the EI app and inject the stored OAuth access token on the way out. Note that this policy can be enhanced to perform additional tasks such as transformation, rate limiting, caching, etc.

Although this use case focuses on the Salesforce API, it is generally applicable to any external API you consume. You can maintain an OAuth session for each API you want to proxy in this Gateway as well as perform identity mapping for other external access control mechanism, for example AWS HMAC signatures.


September 14th, 2011

Last Chance to Register: XACML Authorization Workshop

Written by
Category Events
 

At the beginning of next week, in Washington DC, Layer 7 will be co-sponsoring an XACML workshop with Axiomatics, SailPoint and Radiant Logic. We plan to keep accepting registrations up to the end of this week but the workshop is limited to 30 participants and spaces are going fast. So, if you’re in DC and you want to learn how to build a cutting-edge authorization service using XACML, click here to sign up now!

With the identity management industry increasingly moving towards standards-based authorization, the concepts explored in this intensive two-day workshop will be vital for anyone who needs to build a truly up-to-date authorization service that ensures regulatory requirements and internal policies are consistently enforced across all application platforms.

Here are the full details:

XACML Training Workshop
MicroTek Training Center
3rd Floor – 1101 Vermont Avenue NW
September 19-20, 2011
Washington, DC

Agenda
Day 1: XACML Introductory Concepts & Complementary Technologies

  • Authorization concepts
  • Common use cases
  • Attribute-based access control
  • Extending authorization to Web services and REST apps
  • Managing attributes
  • Addressing compliance and governance

Day 2: XACML Details & Advanced Topics

  • XACML policy language constructs
  • XACML request/response protocol
  • Attribute-based access control
  • Policy modeling best practices
  • XML gateway integration
  • Virtual directory integration
  • Access governance integration

 

September 13th, 2011

ArcSight CEF Certification for Layer 7 Gateways

Written by
Category Security
 

I’m excited to announce that HP has just awarded ArcSight Common Event Format (CEF) certification to Layer 7’s SecureSpan and CloudSpan product suites. We’ll be proudly demoing our newly-certified CEF integration at the ArcSight Protect 2011 show in Washington DC, September 11-14.

To whet your appetite, I’d like to provide a quick preview of precisely what we’ll be demoing. Essentially, what we’re talking about here is a hybrid risk-management solution for the extended enterprise, based on integration between the Layer 7 gateway and HP’s ArcSight Enterprise Threat and Risk Management (ETRM) platform.

ETRM helps enterprises collect and analyze data on security risks. Layer 7’s support for ArcSight’s native CEF specification creates an awareness of and visibility into security threats in situations where applications and services are extended beyond normal enterprise boundaries – for example, when they are deployed in the cloud or made available on mobile devices.

The core value of the Layer 7/ETRM integration comes from its ability to correlate cross-domain security data. Layer 7’s CEF integration achieves this by allowing ETRM users to map events and identities associated with external entities to known internal identities. This creates an end-to-end view of access control decisions based on user credentials, organizations and roles.

Our product suite is particularly well placed to map this information as it delivers an extremely rich set of identity features. SecureSpan and CloudSpan support a wide variety of credential types, authentication servers and authorization mechanisms. They also deliver standards-based Security Token Service functionality for additional credential mapping.

Layer 7’s CEF support also creates a comprehensive view of application usage and vulnerabilities. For example, when an application interface is exposed to external consumers as an API, Layer 7 can enforce security policies on external application requests and extract usage data essential to event correlation across all executions of the application.

If you’re going to be at ArcSight Protect and you’d like to see what all this looks like in practice, stop by booth 37. I’ll see you there!

September 9th, 2011

Accelerating Security & Governance with SOA

Written by
Category Security, SOA
 

This week I gave a talk at ITP’s SOA, BPM & Integration Forum in Zurich, a one-day conference with analyst presentations, customer case studies and one-to-one sessions.My talk, called “Accelerating Security & Governance with SOA”, had two main aims:

  • To provide an overview of how and why many organizations are accelerating the design and deployment of SOA security and governance environments
  • To discuss (and hopefully provide answers to) questions arising from this acceleration

To give you an idea of the ground I covered in my presentation, here’s a link to the slide deck I used. I’d also like to take a moment here to explain why I believe the acceleration of SOA security and governance programs is an important issue that demands our attention at this time.

First of all, SOA is continuing to expand throughout organizations, across organizational boundaries and into the Cloud. Organisations are reacting as dynamically as they can to the integration challenges this creates. At the same time, security and governance need to keep up, so the smart players are also accelerating these aspects of their SOA environments.

Second, the acceleration of SOA security and governance programs creates issues of its own. While, the rapid infrastructural changes created by growth in SOA and Cloud adoption certainly need to be managed and security must be enforced consistently, acceleration of security and governance raises a number of tricky questions, which I endeavoured to tackle in my talk:

  • How do you manage the implementation of SOA security and governance without slowing down your organisation?
  • How will your SOA remain operational as it evolves?
  • How can you deliver APIs quickly while enforcing perimeter security and integration?

I got some very interesting feedback on my answers at the forum and I’m certainly looking forward to hearing more from the online community!

Accelerating SOA Security and Governance

September 1st, 2011

Clouds On A Plane: VMware’s Micro Cloud Foundry Brings PaaS To My Laptop

On the eve of this week’s VMworld conference in Las Vegas, VMware announced that Micro Cloud Foundry is finally available for general distribution. This new offering is a completely self-contained instantiation of the company’s Cloud Foundry PaaS solution, which I wrote about earlier this spring. Micro Cloud Foundry comes packaged as a virtual machine, easily distributable on a USB key (as they proved at today’s session on this topic at VMworld), or as a quick download. The distribution is designed to run locally on your laptop without any external dependencies. This allows developers to code and test Cloud Foundry apps offline, and deploy these to the cloud with little more than some simple scripting. This may be the killer app PaaS needs to be taken seriously by the development community.

The reason Micro Cloud Foundry appeals to me is that it fits well with my own coding style (at least for the small amount of development I still find time to do). My work seems to divide into two different buckets consisting of those things I do locally, and the things I do in the cloud. More often than not, things find themselves in one bucket or the other because of how well the tooling supports my work style for the task at hand.

As a case in point, I always build presentations locally using PowerPoint. If you’ve ever seen one of my presentations, you hopefully remember a lot of pictures and illustrations, and not a lot of bullet points. I’m something of a frustrated graphic designer. I lack any formal training, but I suppose that I share some of the work style of a real designer—notably intense focus, iterative development, and lots of experimentation.

Developing a highly graphic presentation is the kind of work that relies as much on tool capability as it does on user expertise. But most of all, it demands a highly responsive experience. Nothing kills my design cycle like latency. I have never seen a cloud-based tool for presentations that meets all of my needs, so for the foreseeable future, local PowerPoint will remain my illustration tool of choice.

I find that software development is a little like presentation design. It responds well to intense focus and enjoys a very iterative style. And like graphic design, coding is a discipline that demands instantaneous feedback. Sometimes I write applications in a simple text editor, but when I can, I much prefer the power of a full IDE. Sometimes I think that IntelliJ IDEA is the smartest guy in the room. So for many of the same reasons I prefer local PowerPoint for presentations, so too I prefer a local IDE with few if any external dependencies for software development.

What I’ve discovered is that I don’t want to develop in the cloud; but I do want to use cloud services and probably deploy my application into the cloud. I want a local cloud I can work on offline without any external dependency. (In truth, I really do code on airplanes—indeed some of my best work takes place at 35,000 feet.) Once I’m ready to deploy, I want to migrate my app into the cloud without modifying the underlying code.

Until recently, this was hard to do. But it sounds like Micro Cloud Foundry is just what I have been looking for. More on this topic once I’ve had a chance to dig deeply into it.