Access control is a key aspect of API management. When an enterprise launches an API, identity and access management (IAM) will be among its most pressing concerns. But access control is handled differently for APIs than it is for the Web or even Web services. This can present difficulties for an enterprise that wants to reuse its existing IAM  infrastructure to provide access control for APIs.

On March 14, I’ll be co-presenting a webinar called Simplifying API Access Control with OAuth, alongside Steve Coplan of 451 Research. We’ll be exploring a good deal of the ground around API access control and OAuth but with a particular focus on how existing IAM and Single Sign-On (SSO) systems can be extended to integrate with API-enabled applications and services.

In addition to discussing how enterprises can extend their existing IAM and SSO investments for API access, we’ll be looking at:

• What security and management concerns are created by open APIs
• How enterprises can address key IAM challenges when securing APIs
• Why OAuth is becoming central to API access control

Space is limited – so, if you’re interested, sign up today!

Tokens are at the center of API access control in the enterprise. Token management, the process through which the lifecycle of these tokens is governed, emerges as an important aspect of enterprise API management.

OAuth access tokens, for example, can have a lot of session information associated with them:

• Scope
• Client ID
• Subscriber ID
• Grant type
• Associated refresh token
• A SAML assertion or other token the OAuth token was mapped from
• How often it’s been used, from where

While some of this information is created during OAuth handshakes, some of it continues to evolve throughout the lifespan of the token. Token management is used during handshakes to capture all relevant information pertaining to granting access to an API and it makes this information available to other relevant API management components at runtime.

During runtime API access, applications present OAuth access tokens issued during a handshake. The resource server component of your API management infrastructure, the Gateway controlling access to your APIs, consults the token management system to assess whether or not the token is still valid and to retrieve information associated with it, which is essential to deciding whether or not access should be granted. A valid token is not in itself sufficient. Does the scope associated with it grant access to the particular API being invoked? Does the identity (sometimes identities) associated with it also grant access to the particular resource requested? The token management system also updates the runtime token usage for later reporting and monitoring purposes.

The ability to consult live tokens is important not only to API providers but also to owners of applications to which they are assigned. A token management system must be able to deliver live token information, such as statistics, to external systems. An open API-based integration is necessary for maximum flexibility. For example, an application developer may access this information through an API developer portal, whereas an API publisher may get this information through a BI system or ops-type console. Feeding such information into a BI system also opens up the possibility of detecting potential threats from unusual token usage (frequency, location-based etc.) Monitoring and BI around tokens therefore relates to token revocation.

As mobile applications represent one of the main drivers of API consumption in the enterprise, the ability to easily revoke a token when, for example, a mobile device is lost or compromised is crucial to the enterprise. The challenge around providing token revocation for an enterprise API comes from the fact that it can be triggered from so many sources. Obviously, the API provider itself needs to be able to easily revoke any tokens if a suspicious usage is detected or if it is made aware of an application being compromised. Application providers may need the ability to revoke access from their side and – obviously – service subscribers need the ability to do so as well. The instruction to revoke a token may come from enterprise governance solutions, developer portals, subscriber portals etc.

Finally, the revocation information is essential at runtime. The resource server authorizing access to APIs needs to be aware of whether or not a token has been revoked.

The management of API access tokens is an essential component of enterprise API management. This token management must integrate with other key enterprise assets, ideally through open APIs. At the same time, token data must be protected and its access secured.

The Enterprise is buzzing with API initiatives these days. APIs not only serve mobile applications, they are increasingly redefining how the enterprise does B2B and integration in general. API management as a category follows different models. On one hand, certain technology vendors offer specialized infrastructure to handle the many aspects of API management. On the other, an increasing number of SaaS vendors offer a service which you subscribe to, providing a pre-installed, hosted, basic API management system. Hybrid models are emerging but that’s a topic for a future post.

Before opting for a pure SaaS-based API management solution, think about these key considerations:

The Cloud Advantage
One can realize the benefits of Cloud computing from an API management solution without losing the ability to control its underlying infrastructure. For example, IaaS solutions let you host your own API management infrastructure. Private Clouds are also ideal for hosting API management infrastructure and provide the added benefit of running "closer" to key enterprise IT assets. Through any of these SaaS alternatives, an API management infrastructure optimizes computing resource utilization. IaaS and private Cloud-based API management infrastructure also provide elasticity and can scale on demand. Look for an API management solution that offers a virtual appliance form factor to maximize the benefits of Cloud.

Return on Investment
The advantage of a lower initial investment from SaaS-delivered API management solutions quickly becomes irrelevant when the ongoing cost of a per-hit billing structure increases exponentially. With your own API management infrastructure in place, you can leverage an initial investment over as many APIs as you want to deliver, no matter how popular the APIs become. Many early adopters, which originally opted for the SaaS model, are currently making the switch to the infrastructure model in order to remedy a monthly cost that has grown to unmanageable levels. Unfortunately, such transitions are sometimes costing more than any initial costs savings.

Agility, Integration
SaaS solutions provide easy-to-use systems isolated in their own silos. This isolation from the rest of your enterprise IT assets creates a challenge when you attempt to integrate the API management solution with other key systems. Do you have an existing Web portal? How about existing identity, business intelligence or billing systems? If your API management solution is infrastructure-based, you have access to all the low-level controls and tooling that are required to integrate these systems together. Integrating your API management with existing identity infrastructure can be important to achieving runtime access control. Integrating with billing systems is crucial to monetizing your APIs. Feeding metrics from an API management infrastructure into an existing BI infrastructure provides better visibility.

Security
Depending on the audience for your APIs, various regulations and security standards may apply. Sensitive information traveling through a SaaS-based system is outside your control. Are any of your APIs potentially dealing with cardholder information? Does PCI-DSS certification matter? If so, a SaaS-based API management solution is likely to be problematic. In addition to the off-premise security issue, SaaS-based API management solutions offer limited security and access control options. For example, the ability to decide which versions of OAuth you choose to implement matters if you need to cater to a specific breed of developers.

Performance
Detours increase latency. By routing API traffic through a hosted system before it gets to the source of the data, you introduce detours. By contrast, if you architect an API management infrastructure in such a way that runtime controls happen in the direct path of transaction, you minimize latencies. For example, using the infrastructure approach, you can deploy everything in a DMZ. Also, by owning the infrastructure, you have complete control over the computing resources allocated to it.

I'll be touching upon some of these issues when I give a presentation called Enterprise Access Control Patterns for REST & Web APIs on March 2, at the RSA Conference in San Francisco.

Late in 2011, we started a series of tutorials aimed at illustrating how Layer 7’s SecureSpan Gateways can be used to implement various aspects of the OAuth 2.0 specification as a means for controlling access to enterprise APIs. In this fifth OAuth-focused tutorial, we look at how you can integrate existing CA SiteMinder Single Sign-On (SSO) sessions as part of an OAuth handshake.

For situations where a service subscriber already has an SSO experience provided by CA SiteMinder, the SecureSpan Gateway can be leveraged to enable an application to consume the API on behalf of the subscriber, using OAuth. The objective is to maintain the end user’s SSO experience during the handshake while still complying with the OAuth 2.0 specification.

Tutorial 5: Leverage a CA SiteMinder Session in an OAuth 2.0 Handshake

As promised, here’s another of my weekly tutorial videos on how Layer 7’s OAuth Toolkit can be used to leverage the many grant types and use cases supported by the OAuth 2.0 standard. I’m glad to report that there has been a lot of interest in this series of videos. We get queries about OAuth just about every day, so enterprise architects clearly see this emerging standard as a potentially powerful tool for controlling access to APIs.

For those of you who haven’t seen my previous OAuth 2.0 tutorials, I should explain that the OAuth Toolkit provides a number of OAuth template implementations that can be imported into our Gateways in order to apply OAuth. This template integrates into existing environments by connecting with identity providers and APIs.

This week, I’m explaining the OAuth 2.0 SAML grant type. This grant type is defined in an OAuth extension specification (draft-ietf-oauth-saml2-bearer-09), which defines another grant type not included in the core OAuth specification. This grant type describes how a client application uses a SAML bearer assertion to obtain an OAuth access token.

Although this specification does not describe how the client application obtains the SAML assertion in the first place, the tutorial does use a test application to provide an example in which the user is forwarded to a SAML identity provider which authenticates the user, issues a SAML assertion and redirects the user back to the application. The application then uses this redirected SAML assertion to obtain an access token from the Layer 7 Gateway’s OAuth authorization server endpoint.

Tutorial 4: The SAML Grant Type