June 19th, 2012

Layer 7 at Gartner AADI

Written by
 

Gartner SummitsLayer 7’s UK team will be talking mobile, open APIs and cloud this week at the Gartner Application, Architecture, Development & Integration Summit, in London. We are longstanding supporters of Gartner AADI in the UK, US and Australia because of the value it offers enterprise architects, development managers and integration leaders facing challenges around mobile, APIs and the cloud. As enterprises face more complex hybrid connectivity problems over the coming years, we expect conferences like this will play a central role in providing a gathering place for IT experts tasked with finding solutions.

If you’re attending this year’s London event, come by Layer 7′s booth to learn about our new mobile offerings or enjoy the company of the Queen herself during a special hospitality event, where we’ll be celebrating her Diamond Jubilee. Also, if you get the opportunity, don’t miss the chance to hear Rhys Jones from Royal Bank of Scotland (a Layer 7 customer) talking about his organization’s journey to the cloud.

June 18th, 2012

The Promise of the Web & the Challenge of APIs

Written by
 

QCon LogoOn June 20th, I’ll be presenting a talk at QCon New York on the subject of hypermedia APIs. While the title may sound a bit “heady” for some, we all deal with hypermedia on the Web every day. If you clicked on the links in the first sentence of this blog post, you were using hypermedia.

My role at Layer 7 is to help business leaders, developers and architects design, develop and deploy world-class APIs – ones that work today and will continue to provide value well into the future. While there’s a good bit of material on the strategic importance, drawing power and business opportunities of APIs, I think more information is needed on how to design and implement APIs that will stand the test of time. And that’s what my QCon talk will be about.

The Web was conceived as a “living” system that could easily accommodate new hardware, software and information. The Web’s incredible growth over the last 20 years proves a complex system like the World Wide Web can actually work in this way but it’s rare that an organization’s developer team is able to successfully design and implement an API strategy that exhibits these same characteristics. Too often, API implementations fail to account for the continued evolution and growth of an organization.

But this level of flexibility and reliability is entirely possible, using technologies and methods we already have today. The key to creating a powerful API, it turns out, is in the design of the messages sent back and forth between parties. Reliable and evolvable API design is based not on function calls and shared objects but on hypermedia-style messages.

Two years ago, I started work on a project to analyze and identify important hypermedia factors used on the Web. This work led to a formal definition of “Hypermedia Types” and the creation of a set of H-Factors that can be used in the design process for creating new, powerful APIs that have the flexibility, usability and longevity of HTML pages themselves. In 2011, my book Building Hypermedia APIs with Node & HTML5 was published and – in less than a year – the methodologies and techniques outlined in that book have begun to appear in API designs by Nokia Research, CloudApp, RStatus and others.

My talk will cover not only the basics of Hypermedia APIs but also some of the successes and challenges these (and other) companies encountered in moving from fixed RPC-style application interfaces rooted in local network application models to more powerful and extensible hypermedia-style interfaces that take advantage of the unique aspects of distributed networks and cloud computing.

For those looking not just at the immediate benefits but also the long-term value of a powerful API strategy, QCon is an excellent conference. There are dozens of great talks on all aspects of software development and I’m honored to be participating in this year’s event. I hope you’ll join me there and that you’ll stop by Layer 7′s booth to say “hello”.

June 14th, 2012

Geofencing & Mobile Access Gateways

Written by
Category API, BYOD, Mobile Access
 

GeofencingOne of the cooler features offered by Siri on the iPhone is its integration with the internal GPS for geofencing. For instance, you can tell her (yes, I just anthropomorphized a disembodied mobile phone app) to “remind me to pick up some milk when I leave the house”. While this geofencing application is very consumer-centric and a nice-to-have, geolocation (and geofencing) is often a must-have for enterprise mobile apps.

At Layer 7, our enterprise customers are sometimes constrained by industry regulations regarding data privacy. These restrictions, especially in the healthcare and financial services industries, often prohibit medical or financial data from traveling across international (or even state) borders, to ensure compliance with local regulations. Some may require additional forms of authentication when connecting from a new physical location.

Many enterprises are also rolling out BYOD initiatives based on the employee’s proximity to company offices – they can use their own phones to access company data while in the office but that access is restricted when they head for home. More complex GIS integration is sometimes necessary for mobile employees and field technicians.

Building strict geolocation rules into every mobile application is possible but time-consuming to develop and difficult to maintain. Managing these policies in a centralized Mobile Access Gateway allows flexibility of design and easy updates. Compliance auditing is simplified and policies are reusable and configuration-driven. If you want to tighten distance restrictions or change GIS providers, you only have to make the change once.

Layer 7′s SecureSpan Mobile Access Gateway is far more than just a simple API proxy. It provides mobile-specific features around identity, security, adaptation, optimization and integration. It is these integration features that allow powerful orchestration of third-party APIs (including geolocation), legacy applications and mobile notification services for a truly comprehensive Mobile Access solution.

June 13th, 2012

Mobile Webinar with Forrester Research, Inc. & Eli Lilly

Written by
 

Forrester-Eli Lily WebinarOn Thursday June 21, Layer 7 will be presenting a live webinar called How to Make Your Enterprise Applications Mobile Ready, Fast, which will include input from Forrester Analyst Jeff Hammond and Tom Nienhaus of Eli Lilly. With issues like BYOD and iPad field enablement becoming increasingly important for many enterprises, this promises to be an extremely interesting webinar.

These issues raise new and highly significant security and management challenges for enterprises. This webinar will look at the most significant mobile challenges facing enterprises and propose some real-world solutions. The goal is to provide practical insight into how on-premise application functionality can be securely exposed, via mobile-friendly APIs, to apps and the developers who build them.

Space is limited so please don’t hesitate to register for the webinar today.

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.