May 27th, 2014

Hybrid App Growth in the Enterprise: Lessons Learned at Gartner AADI

Gartner AADI 2014Last week, I was lucky enough to attend the latest Gartner Application Architecture, Development & Integration Summit in London. One of the key themes that emerged from this show was the need to create agile architectures for mobile apps that leverage enterprises’ backed systems. Architectural agility has long been a central concern for enterprise IT but it has taken on a new urgency with the mobile revolution. As all sorts of enterprises scramble to launch effective mobile app strategies, the issue of how to build agile architectures for the mobile domain is ever more pressing.

One of the key questions for architects charged with enabling enterprise app strategies is whether enterprises should be developing fully native mobile apps, building apps on Web standards like HTML5 or taking a hybrid approach. Based on the sessions I attended and my conversations with architects who are attempting to answer this question in the field, it is clear that each approach has its own advantages and pitfalls. The Web-centric approach enables enterprises to be quick-to-market – a significance advantage in the current climate. But HTML5 simply cannot deliver the kind of rich and seamless functionality offered by native apps.

Logically then, the hybrid approach would seem like the way to go. But even this has its disadvantages. For example, platform vendors like Apple and Google might impose more restrictive terms and conditions on hybrids. Furthermore, hybrid apps retain many of the disadvantages of a Web-centric approach. Hybrids can never deliver the full native experience users prefer and they create significant testing and security challenges. And it’s quite possible that, at some point in the future, mobile development tools could improve to the point where hybrids are no quicker or cheaper to deploy than native apps.

Nevertheless, hybrid apps have significant advantages. First and foremost, the hybrid approach turns the whole “Web-versus-native” binary into a continuum, allowing sophisticated trade-offs to be made between cost/time-to-market and functionality. Furthermore: tools to create hybrid apps are well understood and widely available; unlike pure HTML5 apps, hybrids allow a presence in the app store for marketing purposes; hybrids allow some content and features to be updated without resubmitting the app to the store.

In light of all this, it seems clear to me that the hybrid approach will have a role to play in the ongoing development of enterprise mobility. Indeed, if I remember correctly, one study I heard mentioned said that, by 2016, over half of all mobile apps deployed will be hybrids – whereas less than a quarter were just a year ago. Still, hybrid apps won’t work for every use case and my advice to architects would be to make sure your architectural approach matches the needs and resources of your organization. And whatever approach you take, make sure that it is built on a technology platform that will allow the apps to run smoothly at scale, without impacting the security or performance of backend systems.

April 3rd, 2014

Mobile Access Gateway 2.1 is Here!

Mobile Access GatewayLast week, we launched the Mobile Access Gateway 2.1 in style. The team has worked hard over the past few months to make sure the new features are coming together in a meaningful way. So, what’s in the new release?

First, we now allow customers to configure the usage of SiteMinder Session Cookies, with the Mobile SDK. In fact, the client libraries can use just about any token as the user token without breaking the existing model where we provision and manage token artifacts for users, apps and devices. With 2.1, you can use SiteMinder Session Cookies, SAML, JWT or any other user token. The Gateway administrator can configure what is relevant for the use case. As we know, there is a huge base of SiteMinder users who should now consider the Mobile Access Gateway as their mobility toolkit.

Second, the Mobile Access Gateway now supports social login for mobile apps. Social login support on the Gateway empowers developers to build apps that allow users to securely identify themselves by using sign-on credentials from social network platforms like Google Accounts, Salesforce, LinkedIn and Facebook. The social login flow is supported by the Gateway’s mobile Single Sign-On (SSO) capability. With mobile SSO and social login enabled, users login once with their social account credentials to access multiple enterprise and third-party applications from a mobile device. Additional contextual data such as geolocation can be combined with social login to provide a more secure API.

Third, with the 2.1 release, we now support Adobe PhoneGap. By leveraging the Cordova plugin interface, hybrid apps can tie in to the SSO and mutual SSL session negotiated by the native client libraries. This way, there is a unified security model for native and hybrid apps and app developers can choose to code application logic with their preferred tool chains.

Together with the existing Mobile Access Gateway features, this release provides app developers with better tools for writing awesome and secure mobile apps.

March 27th, 2014

SDK vs API – Round 2

SDK vs APIInspired by a conversation with Kin Lane and Mike Amundsen at last year’s APIdays conference in Paris, I decided to dig deeper into the SDK-vs-API debate.

As I wrote in my last post, I had noticed a pattern of using API SDKs rather than the underlying Web APIs. Let’s quickly define what I mean by SDK. There used to be a time, not so long ago, when “SDK” meant documentation, code samples, build scripts and libraries all bundled together. Today, you find all the former on the Web and usually only the library remains. When I use the term SDK, I mean a programmatic API (e.g. JS, Ruby, PHP, Python) on top of the Web API (usually REST/JSON).

As it happens, my wife gave me a small wearable activity monitor as a Christmas present (I could not possibly think of any reason why I would need that – and the new weight scale in the bathroom must have been pure coincidence). Since the gadget was uploading my stats to a cloud service and this cloud service had an API and my wife gave it to me as a present, I figured I had a perfect excuse to do some coding. My goal was to write a client-side app using JavaScript, pulling my stats from the cloud service via the API (and to keep notes on my experiences).

After registering at the developer portal, I hit my first stumbling block – no client-side JavaScript SDK. The closest I could find was a PHP SDK – which, of course, meant that I had to install PHP (I had not used PHP before) and the framework(s) used by the SDK. I also had to enable a Web server and debug the SDK’s OAuth implementation. That was not quite what I had in mind. Even though I got it running after one day and a half, I ended up being quite frustrated. All that work for a simple Web page displaying the stats for a hardcoded day!

So, I decided to take a different approach and use the SDK provided by Temboo. Again, no client-side Javascript SDK. While I could have used a Node.js SDK instead, I decided to stick with my PHP install and opted for the PHP SDK. From there, the integration was quick and I was up and running within an hour. What I did not like about the SDK was the footprint (it included all possible integrations) and how its abstraction and data presentation leaked into my application code. If I were to build a commercial product using it, I would have to consider the potential stickiness of the SDK. Personally, this did not feel right either. So, I went back to the drawing board and looked at my options.

What had I learned so far? My frame of reference going into the experiment was a client-side app using JavaScript. Yet the only SDKs I had found were written for server-side integration. Since it was the only choice offered to me, I had to invest a significant amount of time finding all the necessary information to get the server-side components and dependencies installed and configured. But even after going through all of this, the experience with either form of SDK left something to be desired.

I had started this exercise thinking that using an SDK was much easier than coding against the Web API – maybe it was time to reassess that assumption.

Looking back at the API documentation, I could not find anything inherently difficult. Looking at the vendor-provided PHP SDK, it dawned on me that the complexity of the client was entirely due to OAuth and the use of XML as payload. This finally gave me the opening I had been looking for. If I could avoid the complexities of OAuth on the client and use JSON as the payload format, I should be able to implement my client-side app with a few lines of JavaScript against the Web API. As a regular guest at Webshell‘s APIdays conference, I was familiar with the company’s OAuth Broker service. It took me a few minutes to get set up, configure the service and download their oauth.js client library. I cut and pasted the sample code into a JavaScript file, consulted the API docs to learn about switching to JSON format and did the API call. I was done in less than five lines of code!

While this experiment is just a single data point, I think it nicely illustrates some of the key lessons in the SDK-vs-API debate. I will attempt to provide a summary from both the API consumer and the API provider perspectives in my next post. I will also be talking about the SDK-vs-API issue in more detail during the upcoming Nordic APIs tour in Stockholm and Copenhagen and at the APIdays conference in Berlin.

February 19th, 2014

End-to-End Mobile Security for Your Consumer Apps

Mobile Security WebinarAccording to Harvard Business Review, 82% of the average user’s mobile minutes are spent using apps, compared to just 18% with Web browsers. Increasingly, the mobile app is replacing the Web site as the primary channel through which consumers get information on or interact with products and services. Consequently, apps have become central to strategic initiatives focused on achieving marketplace differentiation and driving business growth.

For example, look at the way Nike is using an app to drive consumer engagement from the ground up. Runners can use the Nike+ app and device to monitor their performance, collaborate and share information. This is not Nike’s typical elite marketing model, centered on high-profile sports figures but the company attributed 30% of its 2012 running division growth to this app-based approach.

However, adopting an app-based strategy comes with risks. Consumers are using mobile apps to access banking records, healthcare benefit plans and retail accounts. This creates security risks for companies because it requires them to expose backend systems and data via APIs. It also means that consumers’ sensitive information is being placed at risk of compromise.

Businesses have recognized the opportunity at hand, have made mobility a top priority but in the meantime have put security in an awkward position. Information must be exposed and shared in a much more “open” architecture in order to take full advantage of mobile app opportunities. Security must now adapt, focusing on how to protect and reduce the risk in the context of this new open architecture.

What are the options for mobile app security? Solutions exist in a range of categories, including mobile device management (MDM), mobile application management (MAM), containerization, wrapping and more. Generally, these solutions enable a level of control over the device that is not appropriate in consumer scenarios. In fact, many organizations are finding that this level of control is often too restrictive and impinges excessively on user privacy when trying to secure enterprise data on employees’ devices.

What’s the alternative? As previously mentioned, most enterprises’ consumer-facing apps expose valuable backed systems via APIs. Using an API security solution to protect these backend interfaces and the sensitive consumer data they expose is therefore a vital part of the process. It is also vital to control access to the apps that leverage the exposed systems and data. Through the implementation of OAuth and OpenID Connect, organizations can apply risk-based access control to mobile apps. Not only is access controlled to the app but app access to the backend API is also controlled, delivering a complete end-to-end mobile app security solution.

Overall, an acceptable mobile app security solution for consumers should contain a variety of flexible features, including multi-channel authentication, mobile social login, two-factor authentication, geolocation access control, mutual SSL, fine-grained API access control and threat protection against SQL injection, cross-site scripting and DDoS attacks – features that provide an acceptable level of control while maintaining the convenience of the device and preserving the privacy of the user.

To hear more about this, please join tomorrow’s CA Layer 7 webinar as Leif Bildoy and myself walk through the 5 Steps for End-to-End Mobile App Security with Consumer Apps.

February 18th, 2014

A World of Apps & APIs

Apps WorldApplications – and specifically mobile apps – occupy a key battleground for companies trying to woo customers, differentiate their products and drive growth. This is happening across many industries but banking provides a good example. Mobile applications that put banking services in the palm of your hand have become a much more important differentiator than interest rates, which were previously used to lure customers. A well-designed mobile app drives a more engaging experience for customers and this, in turn, drives customer acquisition and retention.

During the recent Apps World show in San Francisco, we saw some examples of this trend and the extraordinary growth right across the application ecosystem. Of course, behind every great app there’s usually a great API and my “State of the Union” address on APIs highlighted the hard work and success we’ve seen over the past few years. But it also served as a reflection on the key areas enterprises much consider as they accelerate innovation via APIs and engage customers in new ways.

Identity and security were recurring themes and we’ll certainly be hearing more about these issues in the coming months. With public awareness of mobile exploits and loss of personal information growing fast, mobile app security is going to dominate the thoughts not just of product managers everywhere but also those of lawmakers seeking to define stricter legislation to protect consumers.

In this context there’s an increasing need to double down on the fundamental requirement for strong-but-user-friendly identity and security functionality in mobile apps. For developers building apps against enterprise APIs, meeting this requirement can be extremely challenging. Thankfully, enterprises can simplify the situation by leveraging the advanced identity and security features of API Management platforms. Right now, app security is often a stumbling block but – by making some smart infrastructural decisions early on – enterprises can turn it into a serious differentiator.