Are you building your APIs the right way?

I keep telling my customers, it is not about what you think is important but it is about what your customers (internal, external or partners) see as important when it comes to building APIs and mobile apps, or APIs for mobile apps. This article from Intel explains the facets of WHO, WHAT and HOW very nicely. We instituted a new practice called Intel API Manager which does all of the above and more. It includes a strategy session to identify the audience (WHO) that can benefit from this, WHAT are the channels that can drive additional revenue, and HOW we can help you achieve that.

http://software.intel.com/en-us/blogs/2013/01/28/taking-your-app-to-market-the-who-what-and-how-of-your-mobile-app-marketing

And, yes Intel does software!  - and very well too!

-Andy Thurai (Twitter: @AndyThurai)

Why are APIs so popular?

Kin Lane recently wrote a couple of blogs about why copyrighting an API is not common. I couldn’t agree more that copyrighting APIs is uncommon. First of all, the API definition is just an interface (It is the implementation detail that is important, and needs to be guarded), so it doesn’t make any sense to copyright an interface. (It is almost like copyrighting a pretty face ). Secondly, the whole idea of exposing an API is you are looking for others to finish the work you started by just providing the plumbing work. Why would anyone want to get involved with a copyrighted API and finish your work for you?

Kin Lane says, “API copyright would prevent the reuse and remix of common or successful API patterns within a space. We are at a point where aggregating common, popular APIs into single, standardized interfaces is emerging as the next evolution in web and mobile app development.”

http://apivoice.com/2012/12/08/api-copyright-would-restrict-api-aggregation/index.php (to read his complete blog).

We have gone from the services aggregation concepts to mashups, and now I am seeing the newer trend of API aggregation.

Keep in mind APIs are generally offered by vendors who want to expose a specific functionality or platform. If you need cross platform, cross provider, cross functionality options, you need to have API aggregations. Remember during the services days how much of a hard time we used to have in integrating and aggregating services from different vendors? I know some companies are making a good living by just building aggregated APIs.

One of the common usage patterns I see time and again is customers use the strongest points from vendors of their choice. This was not possible when you were building services. You ended up buying one vendor stack, and you were limited what was offered by them, unless you custom built the weak parts by yourself.

Now imagine the power of what you are getting now. You are cherry picking the best of breed platforms, best of possible functionalities from multiple vendors of your choice and liking.

I highly encourage you to check out the following solution brief that describes a composite API platform architecture where Intel® has packaged the market leading Mashery API sharing portal with Intel’s gateway security & integration technology to deliver Intel® Expressway API Manager.

 

 

Please contact me if you need more information. I’m more than happy to send you any additional information that you may need.

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

 

 

Who is more sensitive – you or your data?

Sooner or later the following (not so hypothetical quandary) will undoubtedly arise: When moving your data to the cloud, you’ll be faced with an array of decisions that will need to be made. What considerations will you make for the protection of your data? In the not-so-distant past, you most likely invested a lot of time and resources into building “enterprise Ft. Knox” – a state-of-the-art, highly advanced and very expensive solution replete with several sophisticated gadgets, strategically positioned around the enterprise perimeter. You had a moment to breathe a sigh of relief, taking solace in knowing that no one could penetrate the fortress you built. You even went so far as to give yourself a pat on the shoulder, enjoying the moment.

Alas, the respite ended with a tap on the shoulder! The King, also known as the CIO, has informed you that the rules have changed! Apparently, when you were working hard building this impenetrable boundary around the edge fixing the exposure, he made a deal for the kingdom (in this case, your company), that expanded its territory. As a result, the short but life-changing edict is to move processing to a third-world country (in other words to the cloud). Gulp.

Medieval comparisons aside, the matter of fact is that your IT systems have been moved to the cloud – public, private, or hosted. With the stroke of a quill (or pen), the circumscribed limits of your perimeter have changed. Unfortunately, protecting your databases, processes, applications, app servers, web servers, systems, middleware, and back-end systems won’t work anymore, and as in most similar scenarios, you’ll have absolutely no control over them in a cloud environment. It’s highly likely that you won’t even know where things are even running most of the time.

The advantages of moving to the cloud cannot be denied, but the new paradigm-shift is not without headaches and real concerns that come with data privacy, security, auditing, compliance, residency (at certain times you can’t let the data leave certain countries for example), in addition to having to worry about being exposed to hackers on a 24×7 basis.

Now what? Well, there is an easy way to solve this problem. Instead of protecting all of the above, you can simply just protect your data instead. This is exactly where Intel cloud encryption/ data privacy gateways shine. We created these gateways a few years ago, keeping the ever-changing landscape in mind.

So how do we do it? Well, for starters, the Intel cloud encryption gateway is the ONLY solution that is available in multiple form factors – as an appliance, software and virtual. It can also be available as a hosted solution, through our partners if you should choose that option. Our appliances are not “virtual appliances” unlike competing vendors in the market. We provide a “true” appliance. This is imperative in the security field, especially when you need FIPS 140-2 Level 3 compliance in the government (or other highly secure environments like the healthcare) space. (As a side note, I recently read a competitors spec where that company claimed to “enable” you — so you could plug in and use FIPS 140-2 if needed. It’s not certain what they exactly meant or how to parse the finely nuanced language used in their advertisements. In contrast, we are completely straight-forward about our enterprise class capabilities. And, yes, we have that feature built in already.)

In addition, our appliance has a unique set of features that include: tokenization, encryption, Format Preserving Encryption (FPE), as well as others that will help ensure the authenticity, integrity, and validity of your data. That’s not all. What makes us unique is that our cloud encryption gateways are built to fit your current eco-system. This means that regardless of the protocol, identity system, logging system, monitoring system, or data/message type, we can encrypt/tokenize the data that is flowing in and out of your organization.

Let’s think about that for a second. You get these appliances, drop them in the line of traffic, do a few configurations, and you are done. Either you keep the sensitive data and send the tokens to the cloud, or alternatively, send the protected (encrypted) data to the cloud and keep the keys to yourself. This allows you to be compliant and mitigate your risk. There are no more long drawn-out IT engagements, nor nightmare filled sleepless nights trying to figure out what will happen when moving your sensitive data to the cloud.

This is really important where time to market (TTM) is the key. We can have you up and running and poised for being production-ready, in a matter of days (or even in a matter of hours as most cases call for). When making a decision, It’s also essential for your calculus to include ROI and TCO. When you buy a similar solution from someone else, make sure to ask yourself these questions: Will I have to spend hundreds of hours building this? How long will it take me to integrate this within my eco-system? We can get you connected with most existing enterprise systems such as logging, monitoring, auditing, middleware, identity systems, database, (web) services, and SIEM systems such as Arcsight/Nitro quickly. And you get the added advantage of having mobile enablement already built-in.

There’s one last note of chuckle I want to share. I saw a competitor’s blog suggesting that they are rated by Gartner, for tokenization and encryption gateways, and are rated “close enough”, to Intel & McAfee in this area. I just want to close this out by saying we are Intel-McAfee, and we thankfully don’t feel compelled to make similar associations with someone, just to bolster our viability or engender notions of greater stability. We genuinely care for our customers and know that we will be here for many years to come.

I encourage everyone to download a very topical paper on the subject regarding Intel Expressway Tokenization Broker:

 

Please contact me if you need more information. I’m more than happy to send you any additional information that you may need.

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

Composite Distributed Applications and RESTful APIs

I was at Gartner Catalyst last week in San Diego for a luncheon keynote where I explored the concept of a composite distributed application. This is an idea that I have been chewing on for some time and is a direct result of how Enterprises are thinking about application architecture in light of “cloud” and “big data” as well as some of the trends we are seeing in our own customer base for Intel(R) Expressway Service Gateway.

First question: Where do Enterprise applications begin and end in 2012? Let’s state the obvious: the definition of an application as a monolithic piece of object code is ancient history. Let’s try the next definition, a standard n-tier shared nothing web application. This is certainly more timely, but I would also consider it dated.

If we add external cloud services, such as xPaaS (to use Gartner’s terminology) and disparate data warehouses or “big data”, located in geographically dispersed data-centers, this n-tier definition located in a single place doesn’t quite capture all of the application and may leave out important pieces. Key pieces of functionality may live “elsewhere” and this is where our standard enterprise application becomes distributed, with pieces in different physical locations as well as composite which means the inclusion of external xPaaS services such as storage, queuing, authentication or similar services.

So when we think about the larger boundaries of a composite distributed application, what are some salient properties? I came up with the following list for my talk:

Composite Distributed Application Properties

•Hybridized – Includes new feature development as well as the integration of legacy code, which can be done by integrating legacy message or document formats and protocols. In other words, Enterprises don’t want to throw out existing functionality, even if it happens to be written in a different programming language

•Location Independent- Important pieces of logic, persistence and functionality may be split across 1-n clouds, a mix of standard data center deployment, private cloud and public cloud. The application is essentially living across different clouds. All clouds can win.

•Knowledge Complete -  As traditional enterprises emulate web companies with big data analytics and web intelligence, distributed applications must access the results of “Big Data” analytics, which are possibly owned by different factions in the Enterprise. The composite distributed application will need to aggregate results and make important predictions across these sources as well as include any relevant data warehouse and JDBC sources.

•Contextual – Produces just-in-time results based on client context, device and identity. For example, the application I/O model must meet the demands of mobile devices, such as REST APIs, as well as internal enterprise stakeholders

•Accessible & Performs – Produces data compatible with any client on any operating system, with minimal latency. Scales to hundreds of thousands of users where clients are a mix of smart phones, tablets, browsers, or devices.

•Secure and Compliant - Meets compliance and security requirements for data in transit and data at rest, such as PCI, HIPAA and other requirements. This may involve a mix of traditional “coded-in” security,  security at the message level (via a proxy), standard transport level security, and data tokenization prior to analytics

Common Service Layer

A common theme of current Intel service gateway customers is the creation of a common service layer that unifies existing back-end services.What happens is that services grow organically on different platforms and operating systems, written in different languages but can be orchestrated under a common RESTful theme (for more background on REST fundamentals see DZone’s REST Reference Card paper). For instance, many of our customers have a mix of REST-style or SOAP web services and then use a gateway facade or layer to unify these. Unification, however, is only one of the requirements. The second requirement is external exposure to new clients and partners with appropriate performance, trust, threat, and increasingly, throttling/SLA features. Trending right now are OAuth and API key mechanisms, especially when the clients are expected to be mobile devices.

How does this architecture grow into a composite distributed application? This is where location can play a role: as enterprises adopt more cloud PaaS services, their existing services will grow beyond what is found in the data-center, to what is found outside the data-center.

For example, one large service provider that we work with uses Intel Expressway Service Gateway to create a facade for 50+ RESTful services. In the future as they adopt cloud, additional services may also be delivered from the cloud that fit under the facade,  so the RESTful facade and services together may all be properly called “the application”  – here the application is a mash-up of services split among clouds.

We call it “the application” because its all three pieces, the gateway, the internal services and the cloud services that comprises the pieces.  The next question here is how to secure these API interactions and ensure this new breed of application meets performance and compliance requirements.

I think the answer here is that you have to focus on the data itself sent and received at each API hop. This means more emphasis on tokenization and encryption, as well as an understanding of the relevant authentication and authorization controls and how they apply depending on who needs to access the data. For “Big Data” this may mean pre-processing map/reduce input to provide tokenization or encryption prior to performing analytics, essentially ensuring compliance prior to processing.

-Blake

API Whitepaper – Hot off the Press by Andy Thurai

Here is a link to the API whitepaper produced by Dan Woods, Chief Analyst CITO Research (of API book fame); Blake Dournaee, Intel Product Manager; and yours truly.   I think it came out better than expected and has a foreword by John Musser of ProgrammableWeb (Guru in API space). Given that everything is moving to Cloud and Mobile, you might want to spend a few minutes to check out the best practices of developing, implementing, securing and managing your APIs properly regardless of whether you are thinking IasS, PaaS or SaaS. What makes us unique is the combination of McAfee security and Intel identity and performance as you can see in the paper.

Intel API Whitepaper Download Link

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at http://www.linkedin.com/in/andythurai.

Andy Thurai on, “the API – You Can’t Live Without It”

The unprecedented explosion of modern technologies combined with a burgeoning mobile space has forced enterprises to rethink previously held beliefs about the static enterprise perimeter. Remember the olden days when you said your enterprise was completely self-contained in one data center, with your apps inside the firewall and with everyone nearly as confident about it as being as secure as Ft. Knox?  With an explosion in mobile computing, demand for cheap or “free” usage of resources, and a sharp reduction in cost with the cloud delivery model,  it is expected (or rather demanded) that every enterprise expose their APIs not only from their enterprise but from a cloud based model. (NOTE:  The cloud is referred to in a  loosely defined delivery model be it —  public, private, community or hybrid variety).

Couple this inexorable progression for having a cloud based model with the need for mobile enablement and web 2.0 technologies,  and you are forced to expose not only your SOAP APIs,  but also JSON, REST and other fast, quick TTM (time to market) APIs that can be easily manipulated and consumed.

This brings an interesting issue to the fore-front. You are forced to rethink your corporate security strategy. Many organizations (and the C levels that I speak with on a regular basis) are scared to move their sensitive applications (and processes, data) to the cloud, mainly, because of security. But that doesn’t stop them from exploring and moving some of the non-sensitive applications to the cloud and “testing the waters”, so to speak. Once they see how easy and cheap it can be, they begin losing sleep thinking about all of the money they can save by moving everything to the “cloud” due to the constant pressure to plan and come in under budget.

It’s no wonder that API traffic has exploded over the past few years. According to a recent survey, about 60% of the enterprise traffic is API based. According to Programmable Web,  75% twitter traffic is API based. According to Programmable Web there are at least 5000+ APIs (http://blog.programmableweb.com/2012/02/06/5000-apis-facebook-google-and-twitter-are-changing-the-web/) and the pace is growing. Programmable Web has a neat tool where you can search all the publicly available APIs (http://www.programmableweb.com/apis/directory). If you check this out you will immediately notice that most of the social APIs are mostly REST/ JSON based. There is obviously a good reason for that.

When it comes to APIs there are two distinct, broad categories – Social APIs and Enterprise APIs. The Social APIs are created by, and for, our society which is hungry for instant data updates. (Remember the AT&T 4G commercial “so 42 seconds ago”  (http://www.youtube.com/watch?feature=player_embedded&v=bvVVQGgbKk0) . I miss the good old days where we found out what happened in the world by checking CNN website once an hour or so.

In general, the social APIs tend to be fast,  easy to implement, REST only — without any enterprise class security, not monetized,  and focused on publishing  content etc.

You can’t afford to have the enterprise APIs published and consumed the same way. Your Enterprise class security needs to move with your applications API wherever it is going or however it is accessed.  And it is not a question of if, it is a question of when. The success of companies with API as the core of their business models transformed the industry – look at Google, Twitter, Facebook, and other smaller players. According to Programmable Web “The most popular API category from the last 1,000 APIs is government. In total, we list 231 government APIs and nearly half of them have been added in the last four months.”  When the government adopts a technology standard, you know that there is no going back, it is here to stay forever .

As applications migrate out of your own “Ft. Knox”,  the issue will become more pronounced. You’ll still need the same quality of security, management, SLAs,  centralization of usage based information – predicated on policy & identity information.

Most cloud providers just give you the base platform and leave most of this to you.  However, your enterprise class APIs need to provide enterprise class security, governance, lifecycle management , API Key and credential management, throttling and quota management, security, protocol translation and versioning, API performance optimization, key management, discovery. The need to expose your APIs in  multiple formats (as talked above such as REST, JSON, SOAP, etc), can multiply the complexity of an implementation exponentially.

Having set the stage (without wanting to scare you about the inherent risks of exposing your APIs to the cloud), let’s talk about how Intel can help you effortlessly achieve all of these things regardless of your usage model –  without the need to be concerned about whether  APIs are REST based, or full SOAP APIs or even JSON based mobile APIs.

Intel has been in the Web Services, XML, SOAP security space since the acquisition of Sarvega (circa 2005).  Our expansion into the API security space has been a natural progression. We brought out an API security gateway last year which caught the attention of many of our customers. Especially given that it can help enterprises move enterprise grade security policies without having to rewrite the policies (and allow for subsequent enforcement of them in the cloud) makes it even more interesting.

With the addition of OAuth 2.0 to the API gateway in our latest release, it seems like a timely opportunity to talk about the capabilities of our API gateway. When you move your enterprise applications to the cloud and expose APIs from there,you can either retool your application to fit that platform/ delivery model . Or, you have a second option. Use our API gateway as the API middleware which can help you solve a lot of those issues. APIs have become strategic control points for the cloud.

So essentially you want to abstract the following functionality to API middleware:

1. Keep your implementation technology agnostic. Provide a mechanism to support REST, JSON, SOAP, etc and mediate to the backend supported format in a non-intrusive manner. Most times this end result can be achieved by configuring the API gateway solution to act as a facade to the existing application. This is really important in the ever changing API world.  JSON, REST APIs have evolved in the past few years.  By being agnostic, you’ll be prepared for the next “flavor” in whatever way that instantiates itself.
2. Keep your security and API management closer to your APIs and be transparent about it with your  customers.
3. Remove security, scalability, management and audit functionality and issues away from the an actual API implementation.
4. Ensure that you have strong API monitoring, metering, logging, auditing, & versioning features.

Check out our API Gateway details to see how we can help you make this migration easy and painless.

http://software.intel.com/en-us/articles/Cloud-Service-Brokerage-API-Resource-Center/

For more information about Intel Expressway Service Gateway, case studies, testimonials and tech tutorials, please visit www.intel.com/go/identity

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field  and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

Essential Elements of API Management

Here’s a question – do we really care about SOAP or REST any longer? With the advent of cloud and the increased focus on the rapidly changing software consumption model, it seems like Enterprises should come full circle back to API. What do I mean by API in this context? Yes, it’s a programming interface, but as I’ll argue in this post, it’s a generalized programming interface accessible over HTTP. I’m not talking about a .NET DLL or Java RMI interface here.

General interfaces can be implemented in a few ways and the specific implementation (while important) is no longer the salient aspect. Instead, the goal for an Enterprise is how to manage such an API, how to secure it, how to scale it and make it work for the business.

API management, then, is about securing, managing and auditing an increasingly important Enterprise I/O point, one that has enormous potential to connect and expand the Enterprise to new customers through all manner of technology including smart-phone applications, browsers, middleware, legacy applications and just about anything that can talk HTTP.

I also think that this focus on API management is historically connected to SOA and services. Here is how I think we got there:

• First, behind the firewall “SOA” brought low-cost, HTTP-based standard SOAP APIs into the Enterprise mindshare. Rather than thinking in terms of RMI, we can think in a platform independent way and expose interfaces outside the Enterprise.
• Then, Web 2.0 trends and the REST hype coupled with the use of the “WS-* complexity backlash” (new term!) brought REST APIs into the Enterprise mindshare, but Enterprises continued to use SOAP because REST lacked a coherent security model
• Next, the cloud consumption model begins to emerge and software service providers such as Salesforce.com and Amazon want thriving developer communities. Unmarred by any previous history, they offer both SOAP and REST APIs (aka ‘query’ APIs).

If we compose these previous events they lead to a conclusion that moves the discussion from SOA to Services to APIs. I will argue that what Enterprises care about is how to manage API connectivity outside their organization and leave it up to the technology providers to not only make the piping work, but also make it secure, reliable, cheap, scalable, standards-based and compliant. At Intel, we have the concept of a service gateway or enforcement point specifically for this.

From what we’ve seen, there are three conceptual usage models centered on three actors: Enterprise, Service Provider, and Consumer.

The Enterprise is a traditional enterprise normally thought of as one that exposes services to other enterprises for some B2B transaction. Service providers are the term I use to describe a software service provider such as Salesforce.com or Amazon, which expose different types of services (IaaS, PaaS, or SaaS), and Consumers can be end-consumers with a smart-phone, a developer, or thick client.

 

API Management Use Cases

The three use cases are:

1. Enterprise Edge Security – Here the enterprise wants to securely expose services to business partners, with a focus on authentication, auditing, and perimeter security for B2B transactions. A variation on this case is a set of enterprise services exposed to customers, consumed through a tablet or smart-phone. Here is a conceptual picture of the use case with a gateway shown as a control point for the API

1. API Security – Here the service provider wants to securely expose services to customers and developers, with a focus on quality of service enforcement, authentication and API mediation

1. Hybrid Cloud Gateway – This category has three important sub-usage models:
1. Data Gateway – Here the enterprise wants to securely utilize a service provider like Amazon, Microsoft or Google as for additional platform-level services such as queuing and storage. Here the focus is on quality of service enforcement, data protection (encryption/tokenization), authentication and attack prevention
2. Control Gateway – Here the enterprise wants to securely utilize a service provider like Amazon EC2 or Rackspace to as a way to spin-up and spin-down additional server capacity and enforce authentication, authorization and quality of service enforcement on access to external, hosted virtual machine instances.
3. Hosted Edge Security – Here the enterprise deploys a service at a cloud service provider and needs Enterprise class security on the exposed API. Focus is on authentication, attack protection, secure migration and policy consistency between the service provider and Enterprise.

 

The hybrid cloud use cases are shown in the following diagram.

Use case (a) is the conceptual deployment for a control or gateway gateway and use case (b) is the case where an Enterprise is beginning to externally host their infrastructure on a cloud service provider. Here, the gateway is augmenting the API management capabilities provided by the cloud service provider and allowing policies to migrate from the Enterprise to the cloud.

It should be emphasized that there are many, many variations to case (b). Sometimes, the applications themselves are created using the cloud service provider’s own infrastructure, such as Microsoft Azure or Google Apps engine (PaaS). In other cases (depicted in the diagram), it’s Enterprise middleware or other systems migrated to the cloud and hosted (IaaS) with a requirement for Enterprise security policies.

It’s also clear that some of these variations are more speculative than others – it’s an open question whether Enterprises will be willing to risk migrating their core information systems and business processing to the cloud. This is really the big question on everyone’s mind – how much can Enterprises risk today and what can they do to minimize this risk? We think that a service gateway can help minimize this risk, but the Enterprise must place a high degree of trust in the cloud service provider.

These are the three cases that we’ve come across. Notice that the issue of API type is really not at the forefront – any of these could be done with a SOAP/XML, REST/XML or REST/JSON implementation style. What is needed is a way to control and secure these exposed APIs – which is the topic of API management.

I’d love to get comments on this idea and especially new usage models. In some upcoming blogs I’ll be expanding on these and then trying to get into specific details.

-Blake

OAuth2 for the Enterprise? Not so fast… Exploring SAML for REST with Expressway Service Gateway

There has been some recent chatter about the lack of strong, proven standards for API authentication when using the REST paradigm. Recent discussions seem to suggest that 2-Legged OAuth2 is the de-facto champion for securing so called lightweight web services based on the REST paradigm.

The trouble is, for all it’s hype, Enterprises looking to secure critical parts of their B2B communication and supply chain tend to view OAuth2 similar to an excited, overanxious know-it-all teenager, one that you just don’t trust quite yet.

In fact, in talking with some of our potential customers the chief complaint is that OAuth2 doesn’t have the same trusted track record as other established standards, most notably SAML. The problem is, SAML has no official binding for REST based API communication and it is often accused of being too heavyweight due to the XML and XML security processing it imposes on applications. What if there was a way to solve both of these problems for the Enterprise?

At Intel, we’ve long believed that XML is the way to go and the use of an XML Gateway decouples the expensive security, parsing, and transformation features from the developer, making things like SAML processing a snap.

About the second problem. We’ve thought about it and came up with a new feature in the latest version of Expressway Service Gateway that solves the binding problem using a simple approach. Rather than start a new OASIS group or other heavyweight process, we’re suggesting that SAML assertions, either holder-of-key or bearer, be encoded using standard base64 encoding into the HTTP Authorization header. Further, in order to provide an adequate security model, SSL is a must as the assertion itself (while it may be signed) will not be cryptographically bound into the header.

The approach is extremely lightweight and will allow any Expressway customer to protect REST APIs using SAML as the required token mechanism. On the client side, the developer still needs to generate an assertion on their own (or use a gateway product like Expressway), but if they are already using SAML as a token for SOAP messages or other purposes, the assertion is likely already available.

Let’s see how it works in the product. There are two sides to this interaction, the client and then the service. On the client side Expressway can act as a client gateway and attach a SAML assertion to a REST call. To do this, We’ve added a new REST security action to the palette.

In the previous picture, we have a new action that will do the work of creating a new SAML assertion and attaching it into the header. The next question is, how do we control the options? For this, the action is connected to a REST security policy. Here, we are specifying that the output is the HTTP Authorization header and choosing SAML holder-of-key. Remember, for the scheme to be secure, the API call must be done over SSL.

The previous two screen shots suggest a way to generate the assertion and attach it to an outbound call. What about processing it on the service side? For this, we’ve rolled the SAML for REST processing into the existing AAA action.

As you can see in the previous screen shot, all that is needed is a AAA step. The mechanics are pretty simple and extra options are available from the AAA policy – shown in the following screen shot.

In the previous screen shot, you can choose how you want to obtain the assertion. For instance, if you are grabbing the SAML assertion from a standard place (such as SOAP header), a workflow variable, or the two SAML for REST options from the HTTP Authorization header.

We’d really like your feedback and comments on this approach. We’ve already heard the requirement from a few large Enterprise customers – please let us know what you think! -Blake