December 20th, 2012

Top 5 Layer 7 Blog Posts from 2012

Written by
 

Top 5 Layer 7 Blog Posts of 2012To follow up on our Top 5 Resources post from last week, here’s a look at the five most popular, most thought-provoking or just-plain-best posts from the Layer 7 blog in 2012. Mainly though, these are just personal favorites and I should note that they’re arranged chronologically (oldest first), not in order or preference.

The Oracle-Versus-Google Verdict Comes Down
June saw a remarkable amount of media coverage focusing on the world of APIs, as the Oracle/Google court case made headlines. Layer 7’s Jaime Ryan was relieved that the ruling stated APIs are not protected by copyright. Jaime said: “By taking a strong stand on the issue… the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars.”
Read the full post >>>

Are Open APIs Too Open for Big Business?
In July, Ronnie Mitra took a detailed look at how nervous major social media platforms like Twitter and Facebook were becoming about their open APIs and concluded that “enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace… Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.”
Read the full post >>>

Why I Still Like OAuth
In the midst the controversy surrounding July’s formalization of OAuth 2.0, Scott Morrison launched a passionate, though qualified, defense of the standard. Scott argued that “sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done.”
Read the full post >>>

History Repeats: The Search for Agility & Reuse Through APIs
This September, Dimitri Sirota visited the SDP Global Summit in Rome and noticed how much of the discussion around telecom carriers’ API initiatives echoed the SOA talk of a decade ago. He noted “telco after telco (echoed) the decade-old SOA mantra of abstraction, agility and reuse when talking about their new API initiatives… But if Web APIs are to deliver on the SOA vision of agility and reuse, they will need some of the same plumbing that made Web services work.”
Read the full post >>>

RESTful or Not?
Also in September, Mike Amundsen provided an explanation of the key term “RESTful”, which is so often used in reference to APIs and Web services. Mike explained: “Essentially, REST… is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that ‘an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference’.”
Read the full post >>>

November 9th, 2012

Runtime Token Mapping for Mobile API Traffic

OAuth for MobileHere’s an interesting pattern that we’re constantly running into at various API Management projects: runtime mapping between a token used by external mobile applications and another form of authentication required by an internal system. The need for this comes up when a legacy API/service with an existing access control mechanism needs to be exposed to a mobile application for which the current access control mechanism is not appropriate.

Example 1: Kerberos-Constrained Delegation
Services and APIs developed using Microsoft stacks often expect a Windows identity at runtime for role-based authorization. Providing a Kerberos ticket all the way to a mobile device outside the security domain is an anti-pattern. Instead, the user of the mobile application is subjected to an OAuth handshake. The authorization server leverages the user credentials at handshake time to also get a Kerberos ticket on behalf of this user and stores it as part of the OAuth session – see the token lifecycle management concept explained in this previous post. The OAuth access token is mapped to the Kerberos ticket at runtime when the API calls are made by the mobile application.

Example 2: An SSO Token
Many backend services were originally intended to be consumed by Web applications. When the user of a Web application logs into the Web portal, a session is created in the IAM solution and when the Web portal needs to consume the internal API on behalf of the user, it leverages this same SSO token. I’m thinking here of solutions such as CA SiteMinder, Oracle Access Manager etc. When this same API is now consumed by a native mobile application, instead of a Web application, the existing login flow is no longer adequate. Again, an OAuth authorization server is leveraged to create a session between the mobile application and the API Management infrastructure. In this case, the OAuth authorization server will get the SSO token created at the same time as the front-side access token and map between the two at runtime.

This pattern is applicable no matter what the internal token is. Other common forms for these internal tokens include a SAML assertion issued by an STS and session IDs issued by the backend service itself through a /login method. Note that baking such login methods directly into an API constitutes an anti-pattern but the token mapping offers a non-intrusive “resolution”, which restores proper decoupling at the perimeter whilst avoiding any change to the legacy backend.

OAuth Handshake
During an initial OAuth handshake, the OAuth authorization server is provided with credentials for the user. These credentials might be provided by the application itself in the case of a resource-owner-password-credentials grant type or by the user via a login form directly on the OAuth authorization server. The best practice is to use password grants for trusted applications (applications provided by the same provider of the API itself) and to use the implicit or authorization-code grant type for third-party applications. These credentials are used by the OAuth authorization server to authenticate the user and issue an access token. In addition to this, the OAuth authorization server may use the user credentials during this same process, to get an internal token issued by doing its own handshake with the internal token server/STS or by making a /login–style API call. The OAuth access token is returned to the mobile application and both tokens are stored as part of the OAuth session, alongside the other properties of the session, such as scope, timestamps etc. Note that there is often a temptation to store the user credentials as part of this session for later use but this is not recommended.

It makes sense to align the life spans of both the internal and external tokens so that they can be reissued together when they expire. Whenever these tokens need to be reissued, the OAuth authorization server will again be the component driving this. For better user experience, the mobile application will often want to avoid prompting the user for credentials. The OAuth standard accommodates this through the concept of refresh tokens but the internal token issuing pattern doesn’t always do that. For example, Kerberos-constrained delegation will let you get a new Kerberos token without the user’s password but other systems will not allow for that. This is often the source of motivation for storing the user credentials as part of the user session as mentioned above. You can instead allow for an internal token with a longer lifespan than the external token and reuse the existing internal token at OAuth refresh time.

Runtime Mapping
At runtime, the mobile application consumes an API on behalf of the user by calling the OAuth resource server, the runtime analog of the OAuth authorization server.

The OAuth resource server is the component responsible for validating an incoming OAuth access token. At runtime, the resource server can retrieve session information associated with the token presented by the application from the token management layer. The resource server will look at the scope and determine whether or not the API call should be authorized or not. When access control is completely assigned to the API Management infrastructure, the resource server makes all the authorization decisions, then passes the API call to the backend API endpoint but in this case, the backend API has its own authorization mechanism. To accommodate this mapping requirement, the resource server retrieves the internal token associated with the access token presented by the mobile application and injects it to the API call to the backend service.

August 22nd, 2012

From the Vault: Understanding Mobile IAM with Forrester Research

Forrester WebinarsIn the new hybrid enterprise, organizations need to manage business functions that flow across their domain boundaries in all directions. Increasingly, this means using APIs as conduits for opening up information to services running in the cloud and apps running on mobile devices like the iPad. For enterprises, securing and governing these APIs is not straightforward.

Meanwhile, BYOD is making Mobile Access an urgent issue for enterprises; forcing them to make application functionality available to app developers in a consistent, easily-consumable, mobile-optimized manner, via APIs. Therefore, enterprise technologies are evolving to support API-based mobile interactions.

Identity and access management (IAM) represents a key concern for enterprise IT and it is particularly crucial in BYOD/enterprise mobile scenarios. Mobile IAM requires fundamentally new approaches and the adoption of new standards such as OAuth.

These are some of the most critical issues facing IT departments today but the associated techniques and technologies are not necessarily that well understood in the enterprise world. Therefore, I’d like to take this opportunity to  flag up some relevant webinars from the Layer 7 archive, all of which feature Forrester Research.

If you’re facing the challenge of ensuring secure access in an enterprise mobile scenario, these resources should help you make sense of the issues:

  • How to Make Your Enterprise Applications Mobile Ready, Fast
    Leverage backend mobile middleware to deliver mobile ready enterprise APIs
    Find out more >>
  • Identity, Access & Privacy in the New Hybrid Enterprise
    Make sense of OAuth, OpenID Connect and UMA
    Find out more >>
  • A Practical Guide to API Security & OAuth for the Enterprise
    Implement OAuth as part of an enterprise-level API security solution
    Find out more >>
August 9th, 2012

OAuth World Tour

OAuth World TourSteve and I had another great Tech Talk in Vancouver this week, discussing the recent controversy around OAuth 2.0 and the state of the standard in general. A couple of questions that came up (thank you Michael and David, among others) were around the availability of libraries for iOS and Android platforms.

Although I’m not as familiar with Android, there definitely seems to be a lack of tooling for enabling OAuth 2.0 on iOS today. The lack of client-side libraries for standards-based access control on mobile devices generally could be problematic for API adoption in the enterprise, as mobile applications represent one of the main targets for enterprise APIs.

Facilitating OAuth on mobile applications is going to be central to my presentation at next week’s Chicago Mobile Meetup where I’ve been invited to speak. At the meetup, we’ll be describing client-side OAuth tooling patterns, exchanging our ideas about different approaches and discussing some code samples.

From there, I will be making my way to Australia for an API Management Breakfast Seminar in Melbourne, where I’ll be talking about API Management in general but also covering the latest in OAuth 2.0 solutions. Finally, I’ll be moving on to the Gartner AADI Summit in Sydney, where Layer 7 will be at booth S6.

August 6th, 2012

To OAuth or Not to OAuth? That is the Question – The Long Road to Standardization for OAuth 2.0

Written by
 

Tech Talk with Francois LascellesTo OAuth or not to OAuth? That seems to be the question many in the API business must ask themselves now that OAuth has moved closer to becoming a standard for authentication. OAuth 2.0 reached a major milestone this week on the road to becoming a standard, when the Internet Engineering Task Force (IETF) approved a draft of OAuth version 2.0. Layer 7′s Chief Architect Francois Lascelles says: “This milestone solidifies the OAuth 2.0 claim of being a standard.”

But OAuth’s journey towards becoming a standard hasn’t been completely smooth. Last week, the original editor of the OAuth 2.0 specification and author of OAuth 1.0, Eran Hammer, resigned and removed his name from the specifications. Layer 7′s own CTO, Scott Morrison, offered his support for the specification in a blog post titled Why I Still Like OAuth, in which he stated: “In the end, OAuth is something we all need and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.”

Still, obvious questions remain: Is OAuth 2.0 a solid protocol for authentication? Should I stop building security architecture around such a tainted specification? What other means are there for authentication if OAuth has become too focused on the enterprise? Francois Lascelles will address these questions as well as discussing and commenting on the recent OAuth 2.0 draft approval during our next live Tech Talk, on August 7. Make sure you add this Tech Talk to your calendar, if you want to get the event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:

And if you’d like to submit some questions: