August 29th, 2013

Steering Safely into the Open Enterprise

Tesla Model SI recently wrote an article for Wired, which discussed the importance of thinking about security at every stage of your application lifecycle.  This is especially important as we enter the new era of open enterprise IT. The explosive growth of mobile computing has shifted the enterprise perimeter and traditional access control mechanisms are no longer sufficient. This is even more relevant when thinking about the Internet of Things (IoT) and its rapidly evolving ecosystem.

George Reese of Dell recently published an article that discusses the Tesla Model S REST API.  This API enables some remote control features on the car and is primarily used by Tesla’s available smartphone apps. Great stuff, showing how mobile meets IOT meets API. The problem is that the focus of the article is all on its potential security vulnerabilities. Where the Tesla developers should be lauded for driving this type of innovation, they are instead scolded for addressing security poorly.

I think this is a great example of where thinking about security all through the lifecycle would have saved the developers some embarrassment. Here are some things for them to think about with the next app or API:

  • Are there other clients besides smartphone apps that I want to access my API?
  • Are there other clients besides smartphone apps that I don’t want to access my API?
  • Are there proven standards or protocols I can use to provide access control?
  • Are there proven tools out there that can help me deliver the solution more quickly?
  • Is there a way for me to revoke a client’s access after it has been granted?

The Tesla team chose to take an unproven path with their authentication solution.  “Security by obscurity” used to be a popular approach but it doesn’t cut it in the open enterprise. In open computing, open and popular protocols like OAuth are the most secure mechanisms to use.  That may seem counter-intuitive but these protocols provide the richest set of implementation tools and breadth of use cases. This allows app developers to focus on their areas of expertise – like automotive innovation – and rely on the security experts for protection.

At Layer 7, our products and services help companies build the foundation for the open enterprise.  Our new Mobile Access Gateway release provides a variety of security capabilities, including smartphone access control and token revocation. Our API Academy helps clients design sustainable APIs that address all aspects of the API lifecycle, including the most practical and comprehensive security protections.

August 26th, 2013

Layer 7 Mobile Access Gateway 2.0

Mobile Access Gateway 2.0Today, Layer 7 introduced version 2.0 of the Mobile Access Gateway, the company’s top-of-the-line API Gateway. The Mobile Access Gateway is designed to help enterprises solve the critical mobile-specific identity, security, adaptation, optimization and integration challenges they face while developing mobile apps or opening APIs to app developers. In the new version, we have added enhancements for implementing Single Sign-On (SSO) to native enterprise apps via a Mobile SDK for Android and iOS.

Too many times, we have seen the effect of bad security practices. My colleague Matt McLarty eloquently discusses the gulf between developers on one hand and enterprise security teams on the other in this Wired article on Tumblr’s security woes. Because these two groups have different objectives, it becomes hard to get a common understanding of how you can secure the enterprise while enabling app developers to build new productivity-enhancing apps. While nobody really wants to be the fall guy who lets a flaw take down a business, we can be sure Tumblr isn’t the last stumble we are going to see.

To prevent you being the next Stumblr, we have taken a closer look at the technologies and practices for authentication of users and apps. No one of these seemed to be adequate alone and – while acknowledging the value of leveraging existing technologies –  we realized that a new approach was needed.

For mobile app security, there are three important entities that need to be addressed: users, apps and devices. Devices are the focus of the MDM solutions many enterprises are adopting and although these solutions are good at securing data at rest they fail to address the other two entities adequately.

Because today’s enterprise apps use APIs to consume data and application functionality that is located behind the company firewall or in the cloud, API security is vital to the success of any enterprise-level Mobile Access program. Therefore, APIs must be adequately secured and access to API-based resources must be controlled via fine-grained policies that can be implemented at the user, app or device level. To achieve this, the organization must be able to deal with all three entities.

Based on this, we have proposed a new protocol that leverages existing technologies. We leverage PKI for identifying devices through certificates, OAuth 2.0 is used to grant apps access tokens and finally OpenID Connect is used to grant user tokens. This new approach, described in our white paper Identity in Mobile Security,  provides SSO for native apps and makes sure the handshake is done with a purpose – to set up mutual SSL for secure API consumption.

Furthermore, this framework is adaptable to changing requirements because new modules can replace or add to existing protocols. For example, when an organization has used an MDM solution to provision devices, the protocol could leverage this instead of generating new certificates. Equally, in some high-security environments, the protocol should be able to leverage certificates embedded in third-party hardware.

To simplify the job for app developers, the Mobile Access Gateway now ships with a Mobile SDK featuring libraries that implement the client side of the handshake. The developer will only have to call a single API on the device with a URL path for the resource as its parameter. If the device is not yet registered or there are no valid tokens, the client will do the necessary handshake to get these artifacts in place. This way, app developers can leverage cryptographic security in an easy-to-use manner, giving users and security architects peace of mind.

August 2nd, 2013

Getting Mobile Mojo Through App Innovation: The Enterprise View

Mobile MojoAPIs first found their footing among consumer Web sites wanting to transform into platforms. APIs let Web sites foster developer communities that could build apps anchored to their services. Innovative apps would attract new users to the Web site, help keep existing users engaged and –with a little bit of luck – make some money.

APIs Engage Developers, Developers Build Apps, Apps Enable Innovation
This virtuous cycle of APIs and innovation does not have to be limited to consumer Web sites. Enterprises have countless data and application resources distributed across their datacenters. All of these could be opened to internal developers via APIs. Done right, this could drive development innovation. Internal programmers with access to diverse internal information resources could build more compelling mobile and cloud apps, in less time.

Centralize API Discovery Through a Directory
Enablement is the starting point for getting developers building better apps, faster. Apps need data and APIs provide the windows into data, both inside the enterprise and out in cloud. Finding the APIs that front the data sources which enrich mobile apps is no easy task. Back in the days of SOA, service directories emerged as the vehicle for helping developers find software service elements that could be reused and composed into diverse business processes.

An API portal can assume a similar role in providing a centralized point of API discovery and reuse in mobile. An API portal provides the core directory, developer management and developer collaboration features that aid mobile innovation. It presents information on what data resources are available and how these resources can be accessed, along with documentation, code samples and so on, all in a simple Web-based format.

Inside vs. Outside Developers
For some time, vendors have been making API portals available from the cloud, with an eye to aiding the external long-tail developer. But that same technology brought inside the datacenter can also be used by internal developers. While external developers can provide a forum for experimentation and education, the real ROI for most enterprises will occur inside the DMZ. Making internal developers building mobile apps productive and agile will help organizations deliver effective consumer and employee-facing apps faster.
But to do this, the API portal will need to be brought inside the firewall where the enterprise will be able manage internal developers securely. This will increase productivity, which will result in more and richer apps, in less time.

Powering the Internal Developer
Having seen the potential service directories had for organizing internal development efforts, Layer 7 has effectively bridged the lessons of SOA to mobile. The Layer 7 API Portal is unique in that it can support classic SOAP services along with newer REST interfaces and can be deployed 100% inside the datacenter. This enables enterprises to use API portals strategically – not just for powering external developer communities. By placing itself at the center of an internal app-building ecosystem, the Layer 7 API Portal can spur innovation across mobile development teams.

July 17th, 2013

Secure APIs: The Road to Business Growth

CA Technologies Mobile SolutionsBusinesses today are under intense pressure to reach new customers, collaborate with new partners and build new mobile apps that transform business processes.

If you’re a bank, you might want to sign customers up using a tablet on the street corner. If you’re servicing cell phone towers, you might want a technician’s tablet or cell phone to know his location, open the right support ticket and send him the proper documentation for that work site. If you’re selling to end customers, you want to give them exactly the information they need, when they need it, on whatever device they choose, when they’re ready to buy.

But when the business comes to IT for such applications, we often tell them “no” – or, at least, “not now.” One reason is that IT is short on developers. But IT’s hesitance also stems from an appropriate concern with issues like access control or the possibility that backend systems might crash under the load from mobile applications or the cost of converting data for these new services and devices. As we learned from connecting our backend systems to the Web, adding a new platform can mean a profound change in how these systems are used – instead of checking a flight once when the travel agent makes a reservation, people now check on-flight information dozens of times as they search for the best flight on the Web or check their mobile phones to see whether Grandma’s flight has arrived yet.

IT can help meet these needs if we realize the business is not asking for a series of huge new standalone apps. What it’s asking for is the ability to experiment, to try a lot of new ideas quickly and at low enough risk and cost that even if some ideas fail, that’s still okay – as long as one or two succeed in a big way. As Linus Pauling put it, “If you want to have good ideas you must have many ideas. Most of them will be wrong and what you have to learn is which ones to throw away.”

Such experimentation is often impossible in-house and not just because of a lack of the skills. The hand-coding process used in most organizations today forces them to build the same app multiple times, once for the browser, once for mobile, once for Google Glass or whatever the next platform is. That not only delays deployment, it also increases cost and risk so much that experimentation in the business is not possible.

But secure APIs can make that experimentation possible. Here’s how.

Secure APIs provide a single gateway for developers from smaller companies that are in your organization’s “ecosystem” to access and monetize the backend systems, databases and information that are your core assets. If you can support outside developers in creating great apps for you, you avoid grinding out that code yourself. That makes you much more agile and reduces your cost and delivery times. It also lets you tap outside developers if you need help in a new or emerging area, such as a Google Glasses app or Big Data or for a short-lived app like one that works with a Super Bowl promotion.

In addition, outside developers might see ways to monetize your internal systems that you cannot. They might come up with, say, a social banking app that builds brand loyalty by using a customer’s social group to encourage her to contribute to a retirement account. They might develop a branded pedometer app for a health plan to track a member’s exercise routine. This is no different than when Twitter or any other social media platform lets third-party developers connect to their information systems, delivering revenue in ways the business might never have imagined.

Organizations taking advantage of this market opportunity are building on a platform that allows them to abstract security and data transformation tasks into a technology layer purpose built to enable this innovation. Think of this as a mobility Gateway that streamlines development and reduces risk by eliminating the need to write everything from security to access control, caching and load management for every application. If those functions are delivered from the Gateway, developers can focus on quick revisions of the front-end application to go after those potential big market wins.

At CA Technologies, we are now providing such a secure Gateway, following our acquisition of Layer 7. The Layer 7 technology provides a secure Gateway that sits in front of your backend systems, exposing them via simple and secure APIs. It provides everything from identity verification to caching through a single security and IT optimization layer, giving developers – and the business – the freedom to experiment and innovate.

The way to build out your APIs is to start slowly using budget from individual projects but keeping the long-term architecture in mind. Don’t try selling it to the business in terms of APIs, caching and security layers. Instead, tell it how you’re giving it the ability to rapidly and securely experiment with new business models at low cost. Talk about how you’re letting it roll out a new mobile application more quickly or giving an outside developer the tools to find a new route to market for you.

We’re seeing that customers who build APIs, not applications, are leveraging the creativity of a world of clever developers. What challenges and rewards have you found on your API journey?

July 11th, 2013

Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity

Identity Federation WebinarThe adoption of cloud by organizations looking for more efficient ways to deploy their own IT assets or as a means to offset the burden of data management drives the need for identity federation in the enterprise. Compounding this is the mobile effect from which there is no turning back. Data must be available any time, from anywhere and the identities accessing it must be asserted on mobile devices, in cloud zones, always under the stewardship of the enterprise.

APIs serve federation by enabling lightweight delegated authentication schemes based on OAuth handshakes using the same patterns as used by social login. The standard specifying such patterns is OpenID Connect where a relying party subjects a user to an OAuth handshake and then calls an API on the identity provider to discover information about the user thus avoiding having to setup a shared secret with that user – no identity silo. This new type of federation using APIs is easier to implement for the relying party as it avoids parsing and interpreting complex SAML messages with XML digital signatures, both of which tend to suffer from interoperability challenges.

Now, let’s turn this around. Sometimes what needs to be federated is the API itself, not just the identities that consume it. For example, consider the common case of a cloud API consumed by a social media team on behalf of an organization. When the social media service is consumed from mobile apps, the cloud API is consumed directly and the enterprise has no ability to control or monitor information being posted on its behalf.

Cloud api consumption by mobile - not federated

In addition to this lack of control, this simplistic cloud API consumption on behalf of an organization by a group of users requires that users share the organization account itself, including the password associated with it. The security implications of shared passwords are often overlooked. Shared service accounts multiply the risk of a password being compromised. There are numerous recent examples of enterprise social media being hacked with disastrous PR consequences. Famous examples from earlier this year include Twitter hacks of the Associated Press leading to a false report of explosions at the White House and Burger King promoting competitor McDonalds.

Federating such cloud API calls involves the applications sending the API calls through an API broker under the control of the organization. Each of these API calls is made through an enterprise identity context, that is each user signs in with its own enterprise identity. The API broker then “converts” these API calls into API calls to the cloud provider using the identity context of the organization.

Cloud api, federated

In this case, federating the cloud API calls means that the enterprise controls the organization’s account. Its password is not shared or known by anybody outside of an administrator responsible for maintaining a session used by an API broker. Users responsible for acting on that cloud service on behalf of the organization can do so while mobile but are authenticated using their enterprise credentials. The ability of a specific user to act on behalf of an organization is controlled in real time. This can, for example, be based on attributes read from a user directory or a predefined white list in the broker itself.

By configuring policies in this broker, the organization has the ability to filter the information sent to and received from the cloud provider. The use of the cloud provider is also monitored and the enterprise can generate its own metrics and analytics relating to this cloud provider.

On July 23, I will be co-presenting a Layer 7 webinar with CA’s Ehud Amiri titled Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity. In this webinar, we will examine the differences between identity federation across Web, cloud and mobile, look at API-specific use cases and explore the impact of emerging federation standards.