Francois Lascelles

Francois Lascelles

As Chief Architect, Francois Lascelles guides Layer 7’s solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology. Now in a field-facing role, Francois helps enterprise architects apply the latest standards and patterns. Francois is a regular blogger and speaker and is also co-author of Service-Oriented Infrastructure: On-Premise and in the Cloud, published by Prentice Hall. Francois holds a Bachelor of Engineering degree from Ecole Polytechnique de Montreal.

June 21st, 2012

Mobile-Friendly Federated Identity: Part 2 – OpenID Connect

 

The idea of delegating the authentication of a user to a third-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 the provider exposes an API that returns information about the 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 that takes an OAuth access token as its input 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 Layer 7′s SecureSpan Mobile Access Gateway OpenID Connect implementation, 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 the variable ${session.subscriber_id} as its input. This variable is automatically set by the Layer 7 OAuth Toolkit as part of the OAuth access token validation. You could easily look up 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, at the time of writing, OpenID Connect is a moving target and the specification is subject to change before finalization.

June 12th, 2012

Mobile-Friendly Federated Identity: Part 1 – The Social Login Legacy

 

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

  • End user experience
  • How easy it is for a relying party to participate
  • How well it meets security requirements

I get easily frustrated when subjected to bad user experience regarding user login and Single Sign-On 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 smartphone 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 the native Facebook app on my smartphone, from which I was able to express consent.

This neat OAuth-ish handshake only required three taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. By the way, 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 that also has its own native app.

Mobile Identity Figure 1 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 could 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 has 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 would be to 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 the 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 series, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities, using standards like OAuth and OpenID Connect with the Layer 7 Gateway.

May 28th, 2012

Gluecon 2012

Gluecon LogoGlue Conference, aka Gluecon, is such a refreshing event – filled with API and application developers, not a single suit in sight, demo pods, hackathons, spheros etc.

APIs are popping up everywhere and creating amazing integration possibilities. One of the coolest demos I saw at Gluecon was Ducksboard’s dashboard service, which lets you create your own monitoring dashboard using a library of widgets for existing social and Cloud providers. You can even create your own widget and have your own data pushed to it via an API endpoint created just for you, on the fly – so sexy!

Thanks to everybody who came to my presentation Making Sense of API Access Control. I hope this shed some light on how to leverage OAuth for controlling access to REST-based APIs. A lot of the new APIs I discovered this week could certainly use some help in that regard. API key authentication in HTTP basic without password has its limitations. The slides from Making Sense of API Access Control are embedded below.

May 23rd, 2012

Public APIs, Private APIs

Publish-a-Private-API-VideoWhen 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 set up 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 lifecycle. 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 actually fall under this category. Many enterprises that are moving forward with API management are exposing APIs privately – for example, to facilitate the creation of custom mobile apps for their employees, in order to tap into the BYOD trend. Those APIs are intended to be consumed by their own developers, contractors and sometimes partners.

The Layer 7 API 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 API Portal.

A series of tutorial videos for the API Portal product has recently been posted on our YouTube channel. As it happens, one of videos is called Publish a Private API and it’s embedded below.

April 11th, 2012

Beyond OAuth – Emerging Standards for API Access Control

 

Beyond OAuthOAuth 2.0 seems to be on everybody’s minds 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 of 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 SecureSpan Gateway platform – a testament to the flexibility of that platform. Then, leveraging precious feedback from numerous architects applying OAuth with our Gateway, the OAuth Toolkit matured; became a product of its own. Today, we’re witnessing the third evolution phase: OAuth is making its way to the very core of the SecureSpan 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 be among the new focuses while building the next generation API management infrastructure.