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.

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.

April 10th, 2012

Faking the Cloud in API Management

API Management - Infrastructure Versus SaaSThe CEO of competitor API management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure-based versus 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 a data-center, others in 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 strengths.

March 8th, 2012

Reminder: Upcoming API Access Control Webinar

Layer 7 WebinarOAuth handshake patterns and OAuth token management are currently two of the hottest topics related to enterprise APIs. Although OAuth originated as a third-party authorization mechanism, it now addresses a multitude of patterns related to controlling access for RESTful APIs. With version 2.0 of the standard defining numerous grant types that accommodate both two and three-legged cases, OAuth is becoming the de-facto standard for any API access control.

Regardless of the specific access control scenario, any enterprise-scale OAuth implementation must leverage existing infrastructure and processes for managing and controlling identities. For example, OAuth should be implemented in a way that maintains any existing Single Sign-On user experience or it should simply reuse existing identities and their attributes as part of the authorization checks.

Next Wednesday, I’ll be joined by Steve Coplan of 451 Research for a webinar called Simplifying API Access Control with OAuth. We’ll be taking an in-depth look at just how OAuth can be integrated with existing systems for effective API access control. We’ve already had a lot of interest in the event but there are still a few free spots, so don’t hesitate to sign up for the webinar today.

February 29th, 2012

Upcoming Webinar: Simplifying API Access Control with OAuth

Extending Existing IAM Technology for Enterprise API Access Control featuring 451 ResearchAccess control is a key aspect of API management. When an enterprise launches an API, identity and access management (IAM) will be among its most pressing concerns. But access control is handled differently for APIs than it is for the Web or even Web services. This can present difficulties for an enterprise that wants to reuse its existing IAM  infrastructure to provide access control for APIs.

On March 14, I’ll be co-presenting a webinar called Simplifying API Access Control with OAuth, alongside Steve Coplan of 451 Research. We’ll be exploring a good deal of the ground around API access control and OAuth but with a particular focus on how existing IAM and Single Sign-On (SSO) systems can be extended to integrate with API-enabled applications and services.

In addition to discussing how enterprises can extend their existing IAM and SSO investments for API access, we’ll be looking at:

  • What security and management concerns are created by open APIs
  • How enterprises can address key IAM challenges when securing APIs
  • Why OAuth is becoming central to API access control

Space is limited – so, if you’re interested, sign up today!

February 13th, 2012

OAuth Token Management

Tokens are at the center of API access control in the enterprise. Token management, the process through which the lifecycle of these tokens is governed, emerges as an important aspect of enterprise API management.

OAuth access tokens, for example, can have a lot of session information associated with them:

  • Scope
  • Client ID
  • Subscriber ID
  • Grant type
  • Associated refresh token
  • A SAML assertion or other token the OAuth token was mapped from
  • How often it’s been used, from where

While some of this information is created during OAuth handshakes, some of it continues to evolve throughout the lifespan of the token. Token management is used during handshakes to capture all relevant information pertaining to granting access to an API and it makes this information available to other relevant API management components at runtime.


During runtime API access, applications present OAuth access tokens issued during a handshake. The resource server component of your API management infrastructure, the Gateway controlling access to your APIs, consults the token management system to assess whether or not the token is still valid and to retrieve information associated with it, which is essential to deciding whether or not access should be granted. A valid token is not in itself sufficient. Does the scope associated with it grant access to the particular API being invoked? Does the identity (sometimes identities) associated with it also grant access to the particular resource requested? The token management system also updates the runtime token usage for later reporting and monitoring purposes.

The ability to consult live tokens is important not only to API providers but also to owners of applications to which they are assigned. A token management system must be able to deliver live token information, such as statistics, to external systems. An open API-based integration is necessary for maximum flexibility. For example, an application developer may access this information through an API developer portal, whereas an API publisher may get this information through a BI system or ops-type console. Feeding such information into a BI system also opens up the possibility of detecting potential threats from unusual token usage (frequency, location-based etc.) Monitoring and BI around tokens therefore relates to token revocation.

As mobile applications represent one of the main drivers of API consumption in the enterprise, the ability to easily revoke a token when, for example, a mobile device is lost or compromised is crucial to the enterprise. The challenge around providing token revocation for an enterprise API comes from the fact that it can be triggered from so many sources. Obviously, the API provider itself needs to be able to easily revoke any tokens if a suspicious usage is detected or if it is made aware of an application being compromised. Application providers may need the ability to revoke access from their side and – obviously – service subscribers need the ability to do so as well. The instruction to revoke a token may come from enterprise governance solutions, developer portals, subscriber portals etc.

Finally, the revocation information is essential at runtime. The resource server authorizing access to APIs needs to be aware of whether or not a token has been revoked.

The management of API access tokens is an essential component of enterprise API management. This token management must integrate with other key enterprise assets, ideally through open APIs. At the same time, token data must be protected and its access secured.