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.

December 2nd, 2013

How I Lost Weight & Learned About APIs

How I Lost Weight with APIsTrying to stay in shape is one of those never-ending life battles that I’ve come to expect as I get older. I’ve bounced between being a healthy shape and a not-so-healthy one for years and I’ve managed to live life just outside the edge of ideal fitness. A few months back, I reached an apex point and dedicated myself to losing a few pounds (again) and set off on a journey to change my life (yet again). Little did I know I’d learn something about APIs along the way.

Everyone has their own way of losing weight but I’ve always preferred a measurable, rationalist approach: I count the calories I consume, I subtract the calories I burn and I budget accordingly. The nice thing is that this method forces me to think about what I’m consuming and what I’m doing. The massive downside is that keeping track of all of the data is a monotonous and soul-destroying effort that often leads to me giving up.

Of course, there is an app for everything now and I started using  a tool to keep a log of foods that I ate along with their associated caloric burdens. One problem with this type of tool is that, while it’s easy to log consumption of food using features like bar code scanners and crowd-based data, the process of logging exercise and calorie expenditure is entirely manual. This can make fitness goals harder to achieve as users like me end up either under or over estimating their daily calorie burn.

Thankfully, devices to monitor your physical exertion do exist and they are reasonably affordable. These are wearable devices that provide a tally of steps taken, stairs climbed and physical exertion throughout the day, providing a wealth of personal data to mine. To be honest, I’d always viewed these devices in the same category as things like Google Glass – really cool pieces of technology that bleeding-edge enthusiasts wear publicly at the cost of their own dignity. But something changed for me when I realized that I’d be able to connect the calorie-counting app I was using with the wearable fitness device. So, I made a purchase.

By connecting the food-tracking application with the activity-tracking device, I was able to get a much more accurate picture of my caloric budget for the day. The systems integrated remarkably well and the quantification of remaining calories along with a few gamification features provided extra incentive for me to keep moving and eat less.

In the end, this behavioral conditioning of triggers, alerts and feedback loops worked well for me and I was able to drop a few pounds. Of course, I lost the tracker on an airplane about a month in and I’m currently racing back towards a pear shape but that isn’t the point. What is more interesting is what we can learn about integration from my journey:

1.  An API is a Great Way to Extend Customer Reach to Platforms
When we think about building APIs, we usually think about extending out to mobile devices or social platforms. But organizations should consider how their products can be extended to niche and non-traditional platforms that their target user base actively uses. If the wearable tracker I purchased didn’t work with the calorie-counting application I was already using, I never would have considered buying the tracker in the first place. But thanks to the API-based integration, I could visualize myself using it and this was the trigger that resulted in a purchase decision.

2.  Integration is Becoming a Core Requirement Instead of a Feature
Something I noticed when scanning the forums on the tracker device’s Web site was the number of posts related to integration with other exercise platforms. For this user base, integration with their favourite run-tracking, calorie-counting or fitness-gamification tools isn’t just a nice-to-have – it is the minimum expectation. It seems that end users are increasingly expecting product vendors to support their platforms of choice and want the freedom to make their own decisions. In other words,  users don’t want to be punished for choosing a less popular tracking tool or a mobile phone operating system that has less market share.

3.  Integration with Potential Competitors can Pay Off
What I didn’t mention in my story was that the fitness tracker I purchased did come with a calorie-consumption-tracking feature. In fact, part of the revenue stream for this product is the sale of subscriptions to the manufacturer’s fitness portal, as part of an end-to-end fitness management program. This means that supporting out-of-the box integration with other fitness trackers actually comes at a potential revenue cost for the tracker vendor. But I would imagine that the overall revenue benefit from attracting customers like myself outweighs the revenue lost from users who choose not to subscribe to the portal. Integrating with competitive products can be a risky proposition but a smart gamble can really pay off.

As interest in the Internet of Things (IoT) continues to increase, I expect to see an increasing variety of interesting device-to-platform integration stories. Businesses will need to have coherent business strategies for extending to this new world, with APIs as an important supporting action.

Also, if you happen to see me in person, don’t forget to tell me how great I’m looking nowadays.