Returning from #CIS2012

July 20, 2012

Cloud Identity Summit was definitely worth the trip. The talks were great, the audience was great, and the venue was outstanding. Sign me up for next year in Napa.

It’s beautiful and quiet at Vail Cascade this morning. As I stepped outside, I’m pretty sure I saw SAML scurrying away in the trees. This is weird given this week’s proclamations that SAML was dead. Although we’re not rid of SAML anytime soon, I do look forward to adoption in the enterprise for the new kid on the block: OpenID Connect. Easier federation, OpenID Connect style is already common for consumer identity providers; enterprise identity providers should take note and follow suit.  As a vendor of API management infrastructure, it’s up to us to enable the enterprise to better reach out to its target audience. I see support for OpenID Connect as a key component in achieving this today.

My favorite proclamation of the week goes to Patrick Harding who declared in his talk titled “The Platiformication of the Enterprise is Upon us Again and they Forgot Security (Again)” that API Tokens are going to be “the currency of the API Economy”. The management of tokens and their lifecycle is indeed a crucial component of API management. Consider the case of a mobile application consuming an Enterprise API using an OAuth token. Such tokens are associated with the API provider, the user (subscriber), the mobile application and the mobile device. Each live token is potentially associated with multiple parties and one of the challenges of API token management is to enable control of the right tokens by the right parties.


Mobile-friendly federated identity, Part 2 – OpenID Connect

June 21, 2012

The idea of delegating the authentication of a user to a 3rd party is ancient. At some point however, a clever (or maybe lazy) developer thought to leverage an OAuth handshake to achieve this. In the first part of this blog post, I pointed out winning patterns associated with the popular social login trend. In this second part, I suggest the use of specific standards to achieve the same for your identities.

OAuth was originally conceived as a protocol allowing an application to consume an API on behalf of a user. As part of an OAuth handshake, the API provider authenticates the user. The outcome of the handshake is the application getting an access token. This access token does not directly provide useful information for the application to identify the user. However, when that provider exposes an API which returns information about that user, the application can use this as a means to close the loop on the delegated authentication.

Step 1 – User is subjected to an OAuth handshake with provider knowing its identity.

Step 2 – Application uses the access token to discover information about the user by calling an API.

As a provider enabling an application to discover the identity of a user through such a sequence, you could define your own simple API. Luckily, an emerging standard covers such semantics: OpenID Connect. Currently a draft spec, OpenID Connect defines (among other things) a “user info” endpoint which takes as input an OAuth access token and returns a simple JSON structure containing attributes about the user authenticated as part of the OAuth handshake.

Request:
GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG

Response:
200 OK
content-type: application/json
{
“user_id”: “248289761001″,
“name”: “Jane Doe”,
“given_name”: “Jane”,
“family_name”: “Doe”,
“email”: “janedoe@example.com”,
“picture”: “http://example.com/janedoe.jpg”
}

In the Layer 7 Gateway OpenID Connect, a generic user info endpoint is provided which validates an incoming OAuth access token and returns user attributes for the user associated with said token. You can plug in your own identity attributes as part of this user info endpoint implementation. For example, if you are managing identities using an LDAP provider, you inject an LDAP query in the policy as illustrated below.

To get the right LDAP record, the query is configured to take as input the variable ${session.subscriber_id}. This variable is automatically set by the OAuth toolkit as part of the OAuth access token validation. You could easily lookup the appropriate identity attributes from a different source using for example a SQL query or even an API call – all the input necessary to discover these attributes is available to the manager.

Another aspect of OpenID Connect is the issuing of id tokens during the OAuth handshake. This id token is structured following the JSON Web Token specification (JWT) including JWS signatures. Layer 7’s OpenID Connect introduces the following assertions to issue and handle JWT-based id tokens:

  • Generate ID Token
  • Decode ID Token

Note that as of this writing, OpenID Connect is a moving target and the specification is subject to change before finalization.


Mobile-friendly federated identity, Part 1 – The social login legacy

June 12, 2012

If I were to measure the success of a federated identity system, I would consider the following factors:

  • End user experience (UX);
  • How easy it is for a relying party to participate (frictionless);
  • How well it meets security requirements.

 

I get easily frustrated when subjected to bad user experience regarding user login and SSO but I also recognize apps that get this right. In this first part of a series on the topic of mobile-friendly federated identity, I would like to identify winning patterns associated with the social login trend.

 

My friend Martin recently introduced me to a mobile app called Strava which tracks bike and run workouts. You start the app at the beginning of the workout, and it captures GPS data along the way – distance, speed, elevation, etc. Getting this app working on my smart phone was the easiest thing ever: download, start the app, login with facebook, ready to go. The login part was flawless; I tapped the Login with Facebook button and was redirected to my native facebook app on my smartphone from where I was able to express consent. This neat OAuth-ish handshake only required 3 taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. BTW, I don’t even know that password, it’s hidden in some encrypted file on my laptop somewhere, so at this point I move on to something else and that’s the end of the app for me. Starting such handshakes by redirecting the user through the native app is the right choice in the case of a native app relying on a social provider which also has its own native app.

Image

Figure 1 – Create account by expressing consent on social provider native app

At this point my social identity is associated to the session that the Strava app has with the Strava API. Effectively, I have a Strava account without needing to establish a shared secret with this service. This is the part where federated identity comes in. Strava does not need to manage a shared secret with me and does not lose anything in federating my identity to a social provider. It still lets me create a profile on their service and saves data associated to me.

When I came home from my ride, I was able to get nice graphs and stats and once I accepted the fact that I have become old, fat and slow, decided to check strava.com on my laptop. Again, a friendly social login button enabled me to login in a flash and I can see the same information with a richer GUI. Of course on my laptop, I do have a session with my social provider on the same browser so this works great. The same service accessed from multiple devices each redirecting me to authenticate in the appropriate way for the device in use.

Now that we’ve established how fantastic the login user experience is, what about the effort needed on the relying party? Strava had to register an app on facebook. Once this is in place, a Strava app simply takes the user through the handshake and retrieves information about that user once the handshake is complete. In the case of facebook on an iOS device, the instructions on how to do this are available here. Even without a client library, all that would be required is implement an OAuth handshake and call an API with the resulting token to discover information about the user. There is no XML, there is no SAML, no digital signatures, and other things that would cause mobile developers to cringe.

Although a good user experience is critical to the adoption of an app, the reasons for Strava to leverage the social network for login go beyond simplifying user login. Strava also happens to rely on the social network to let users post their exploits. This in turn enhances visibility for their app and drives adoption as other users of the same social network discover Strava through these posts.

Although social login is not just about federated authentication, it creates expectations as to how federated authentication should function and what should be required to implement it. These expectations are not just from end users but also from a new breed of application developers who rely on lightweight, mobile-friendly mechanisms.

In the second part of this blog, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities using standards like OAuth, OpenID Connect and the Layer 7 Gateway.

 


Public APIs, private APIs

May 23, 2012

When talking about API management, the first thing that comes to mind is a public API, one that is open for anybody to consume, provided a certain level of registration. Obviously, the most famous APIs are the public ones, potentially known to anybody. However, such APIs only represent a small subset of all APIs that need to be managed. Many APIs that we encounter in the field are setup in such a way that their consumption is restricted to a specific group of developers. This happens for various reasons. Some talk of public and private APIs, others use the terms open and closed to represent the same distinction.

Most of the time, even public APIs start off as private APIs as part of their development life cycle. Until an API has been fully tested and is ready to be launched, it remains private and only accessible to its internal developer base. The ability to “flick the switch” on an API to make it jump from a staging mode to a live mode is an essential feature of an API management infrastructure.

Then there are APIs that are never meant to be public in the first place. Most APIs fall under this category. Many enterprises that are moving forward with API management are exposing APIs that enable them to develop mobile applications for their workforce for example – think of tapping into the BYOD trend. Those APIs are intended to be consumed by their own developers, contractors and sometimes partners.

The Layer 7 API Developer Portal  is geared towards managing APIs that are either public or private and lets API managers control which developers are made aware of which APIs. This lets you have a single point of management for all APIs regardless of their target audience. By default, only public APIs are visible on the Layer 7 API Developer portal.

A series of tutorial videos for our API Developer Portal product has recently been posted to our youtube channel. One such video is How to manage a private API with the Layer 7 Developer Portal at this link.


Beyond OAuth – Emerging standards for API access control

April 10, 2012

OAuth 2.0 seems to be on everybody’s mind these days. I can’t remember an emerging standard picking up interest so fast. The Layer 7 OAuth toolkit evolved through three stages over the last couple years and I’m proud to say that I was involved right from the beginning. It was first developed out of necessity using existing elements of the Layer 7 Gateway solution – a testament to the flexibility of the platform. Then, leveraging precious feedback from numerous architects applying OAuth with our gateway, the OTK matured, became a product of its own. Today, we’re witnessing the 3rd evolution phase: OAuth is making its way to the very core of the Layer 7 Gateway platform.

I mention these different evolution phases because I noticed how different engineers working at these different levels, and in some cases isolated from each other (I travel a lot), identified very similar patterns relating to implementing API access control using OAuth. I’m talking about interaction patterns between various components involved including for example a token issuer, an api consumer, a policy enforcement point, etc. These parties need to discover information at runtime relating to tokens and identities, tokens need to be stored somewhere and managed. It just seems logical that this information would be exchanged via open APIs themselves. Integrating these logical components via APIs means that you can easily separate them as needed and manage their mutual trust. For example, implement the OAuth protocol in a DMZ perimeter zone but store tokens and associated state in the trusted network. API based integration between these different logical components also facilitates the integration of existing IT assets into a new OAuth enabled system.

I recognize many of these patterns in emerging standards building on top of OAuth 2.0 such as OpenID Connect and User Mediated Access (UMA). Coincidence? Obviously not. I expect these emerging standards to become one of the new focuses while building the next generation API management infrastructure.


API Management Deployment Models

April 9, 2012

The CEO of competitor API Management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure vs service based solutions when it comes to API management. Unintentionally, my original post has apparently hit a nerve.

Oren suggests that a “true” cloud solution can only be SaaS-based. While Amazon Web Services among others may take umbrage at that definition I am also a little confused by Oren’s statement since by most definitions Mashery is not a SaaS. Typically, a SaaS provides self-enrollment and self-service aspects. Mashery may let you manage your APIs in the cloud like Layer 7 or Apigee but it doesn’t do this without help from engagement consultants. In that way they are more akin to IBM than Salesforce.

In the end, our customers don’t get too caught up in cloud semantics. Some of our customers want to own a solution, others “rent”. Some want a solution in their datacenter, others on a public cloud. We understand that different deployment models are needed to accommodate different needs. If a cloud deployment is what you are after, try several vendors, verify what you get and compare each solution’s strenghts.


Which grant, which identities – Back from RSA

March 6, 2012

Last week, I had the pleasure of discussing REST access control patterns with Enterprise Architects and partnering technology folks. I also had the opportunity to present on this topic and one of the questions that came up afterwards was from a security architect who was unsure whether OAuth would be a good fit for some existing APIs that they have because those APIs happen to be consumed from two very different sources:

  1. from the inside, by internal applications that do not act on behalf of a particular subscriber but from the provider’s perspective
  2. from the outside, by applications that act on behalf of individual subscribers

OAuth 2.0 provides 4 core grant types that address different situations. In the case of the example described above, you could use the client creds grant type for the first type of access. It should be possible to permit different scopes to different client ids. The internal client ids would be allowed to request wider scopes. For the second type of consumption, the external one, any of the other 3 grant types could be applicable.

Image

Hope to see you at RSA next year,

-fl


Follow

Get every new post delivered to your Inbox.