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.

June 6th, 2013

It’s Official… Layer 7 Joins CA Technologies

Layer 7 and CAThis week, CA Technologies officially closed its acquisition of Layer 7. As a Layer 7 co-founder, this represents the culmination of a decade’s worth of hard work. Equally important, it represents the opening of a new chapter for the company and an opportunity to amplify the vision we have been promoting.

Since our founding, we have preached the vision that enterprises can open their data and application assets programmatically in a secure way. When we started off, the primary driver for opening up was tighter business integration with partners. Today however, the demand for opening up data and application assets has exploded alongside the growth of mobile, cloud, Big Data and the Internet of Things (IoT).

The idea of organizations as walled-off castles is gone. Mobile is forcing organizations to deliver new business apps to customers and employees beyond the enterprise perimeter. Cloud is redefining how applications are consumed and delivered across a hybridized, extended organization. IoT will upend our notions of outside connectivity and data processing. APIs play a central role in making all this happen. Layer 7 gives customers the confidence to open up via APIs, without compromising security or operational integrity.

For us at Layer 7, security has always been a paramount consideration because our customers are enterprises and enterprises care about security. The CA Technologies acquisition reflects a common point of view on how to deliver new business value in mobility, cloud etc. while protecting the data and applications that are the lifeblood of a today’s enterprise.

CA and Layer 7 both appreciate that the old enterprise security perimeter is disappearing and that the only way to effectively enable online business while protecting information assets is to make identity the new perimeter. We need to focus on managing who gets access to what and what they can do with data once they have that access. Put another way, we need to focus on the identity, data and access that drives modern initiatives around Web, mobile, cloud, social and IoT. Together CA Technologies and Layer 7 Technologies offer enterprises the first truly multi-channel approach to enabling the business while securing its information assets.

Looking into the future, one clearly sees the scope for APIs will increase. IoT will make every formerly detached device connected – all through APIs. Where networking used to be about discrete routers and switches, it is now being transformed, via SDN, into something that is programmable and agile – again, this will be brought to you by APIs. And as for the server and storage infrastructure that underpins the data that drives the Web and mobile, Amazon Web Services has given us a glimpse of the future. As the “Web Services” part of that name suggests, APIs will play a significant role in provisioning in management of the cloud.

As we join CA Technologies, we now have the necessary reach and breadth to make Layer 7 the unassailable leader in the API security and management space. For customers, this means more of what they liked plus the ability to accelerate delivery of our original vision. We’re here to help organizations open up via APIs. And we’re open for business.

February 25th, 2013

SSO & OAuth for Mobile Apps – Live Discussion, Feb 26

OAuth SSO Tech TalkIn case you haven’t heard, we are living in the age of mobile applications and the APIs that power them. Sometimes it’s called the API economy.

Smart phones are ubiquitous, social networks are the norm and we are connected to applications on our devices all the time. We love applications like Instagram, Twitter, Evertnote and Snapchat. But we don’t like signing in and out of each of these applications across networks or devices. It’s awkward and cumbersome and we’re often doing it while on the go or commuting, with only one hand to use while tapping in our passwords. Besides, who wants to remember all those passwords anyway? And it’s not safe to use the same one for every application.

This is the major downside of using all these great new mobile applications. Most of us would gladly invite a scenario where we’d only need to log in once to access multiple applications. There’s social login – but is it safe and is our privacy secure? Remember what happened to Burger King’s Twitter account? Enter Single-Sign-On & OAuth for Mobile Applications.

On Tuesday Feb 26, we’ll be hosting a live interactive Tech Talk on security and Single Sign-On (SSO) for mobile applications. And I’m excited to welcome back Layer 7′s Chief Architect and resident OAuth expert Francois Lascelles. He’ll discuss how to provide SSO for mobile applications, without compromising the security of the apps or the APIs that power them. Francois will also be taking your questions throughout the Tech Talk. So, this will be a great opportunity to get answers to your questions about your own applications and the security that surrounds them.

Click here to get the event details and a reminder in your calendar.

On the day of the event, click here to join:

Submit your questions:

January 4th, 2013

Give Me a JWT, I’ll Give You an Access Token

 

JSON Web TokenOne of the common misconceptions about OAuth is that it provides identity federation by itself. Although supporting OAuth with federated identities is a valid pattern and is essential to many API providers, it does require the combination of OAuth with an additional federated authentication mechanism. Note that I’m not talking about leveraging OAuth for federation (that’s OpenID Connect) but rather an OAuth handshake in which the OAuth authorization server (AS) federates the authentication of the user.

There are different ways to federate the authentication of an end user as part of an OAuth handshake. One approach is to simply incorporate it as part of the authorization server’s interaction with the end user (handshake within handshake). This is only possible with grant types where the user is redirected to the authorization server in the first place, such as implicit or autz code. In that case, the user is redirected from the app, to the authorization server, to the identity provider (IDP), back to the authorization server and finally back to the application. The federated authentication is transparent to the client application participating in the OAuth handshake. The OAuth spec (which describes the interaction between the client application and the OAuth authorization server) does not get involved.

illustration1

Another approach is for the client application to request the access token using an existing proof of authentication in the form of a signed claims (handshake after handshake). In this type of OAuth handshake, the redirection of the user (if any) is outside the scope of the OAuth handshake and is driven by the application. However, the exchange of the existing claim for an OAuth access token is the subject of a number of extension grant types.

One such extension grant type is defined in the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification, according to which a client application presents a SAML assertion to the OAuth authorization server in exchange for an OAuth access token. The Layer 7 OAuth Toolkit has implemented and provided samples for this extension grant type since its inception.

illustration2

Because of the prevalence of SAML in many environments and its support by many identity providers, this grant type has the potential to be leveraged in lots of ways in the enterprise and across partners. There is, however, an emerging alternative to bloated, verbose SAML assertions – one that is more “API-friendly”, based on JSON: JSON Web Token (JWT). JWT allows the representation of claims in a compact, JSON format and the signing of such claims using JWS. For example, OpenID Connect’s ID Tokens are based on the JWT standard. The same way that a SAML assertion can be exchanged for an access token, a JWT can also be exchanged for an access token. The details of such a handshake are defined as part of another extension grant type defined as part of JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.

Give me a JWT, I’ll give you an access token. Although I expect templates for this extension grant type to be featured as part of an upcoming revision of the OAuth Toolkit, the recent addition of JWT and JSON primitives enables me to extend the current OAuth authorization server template to support JWT bearer grants with a Layer 7 Gateway today.

The first thing I need for this exercise is to simulate an application getting a JWT claim issued on behalf of a user. For this, I create a simple endpoint on the Gateway that authenticates a user and issues a JWT returned as part of the response.

idppolicy

Pointing my browser to this endpoint produces the following output:

idoutput

Then, I extend the authorization server token endpoint policy to accept and support the JWT bearer grant type. The similarities between the SAML bearer and the JWT bearer grant types are most obvious in this step. I was able to copy the policy branch and substitute the SAML and XPath policy constructs for JWT and JSON path ones. I can also base trust on HMAC-type signatures that involve a share secret, instead of a PKI-based signature validation, if desired.

newAS

I can test this new grant type using a REST client calling the OAuth authorization server’s token endpoint. I inject into this request the JWT issued by the JWT issuer endpoint and specify the correct grant type.

illustration5

I can now authorize an API call based on this new access token, as I would any other access token. The original JWT claim is saved as part of the OAuth session and is available throughout the lifespan of this access token. This JWT can later be consulted at runtime when API calls are authorized inside the API runtime policy.

November 9th, 2012

Runtime Token Mapping for Mobile API Traffic

OAuth for MobileHere’s an interesting pattern that we’re constantly running into at various API Management projects: runtime mapping between a token used by external mobile applications and another form of authentication required by an internal system. The need for this comes up when a legacy API/service with an existing access control mechanism needs to be exposed to a mobile application for which the current access control mechanism is not appropriate.

Example 1: Kerberos-Constrained Delegation
Services and APIs developed using Microsoft stacks often expect a Windows identity at runtime for role-based authorization. Providing a Kerberos ticket all the way to a mobile device outside the security domain is an anti-pattern. Instead, the user of the mobile application is subjected to an OAuth handshake. The authorization server leverages the user credentials at handshake time to also get a Kerberos ticket on behalf of this user and stores it as part of the OAuth session – see the token lifecycle management concept explained in this previous post. The OAuth access token is mapped to the Kerberos ticket at runtime when the API calls are made by the mobile application.

Example 2: An SSO Token
Many backend services were originally intended to be consumed by Web applications. When the user of a Web application logs into the Web portal, a session is created in the IAM solution and when the Web portal needs to consume the internal API on behalf of the user, it leverages this same SSO token. I’m thinking here of solutions such as CA SiteMinder, Oracle Access Manager etc. When this same API is now consumed by a native mobile application, instead of a Web application, the existing login flow is no longer adequate. Again, an OAuth authorization server is leveraged to create a session between the mobile application and the API Management infrastructure. In this case, the OAuth authorization server will get the SSO token created at the same time as the front-side access token and map between the two at runtime.

This pattern is applicable no matter what the internal token is. Other common forms for these internal tokens include a SAML assertion issued by an STS and session IDs issued by the backend service itself through a /login method. Note that baking such login methods directly into an API constitutes an anti-pattern but the token mapping offers a non-intrusive “resolution”, which restores proper decoupling at the perimeter whilst avoiding any change to the legacy backend.

OAuth Handshake
During an initial OAuth handshake, the OAuth authorization server is provided with credentials for the user. These credentials might be provided by the application itself in the case of a resource-owner-password-credentials grant type or by the user via a login form directly on the OAuth authorization server. The best practice is to use password grants for trusted applications (applications provided by the same provider of the API itself) and to use the implicit or authorization-code grant type for third-party applications. These credentials are used by the OAuth authorization server to authenticate the user and issue an access token. In addition to this, the OAuth authorization server may use the user credentials during this same process, to get an internal token issued by doing its own handshake with the internal token server/STS or by making a /login–style API call. The OAuth access token is returned to the mobile application and both tokens are stored as part of the OAuth session, alongside the other properties of the session, such as scope, timestamps etc. Note that there is often a temptation to store the user credentials as part of this session for later use but this is not recommended.

It makes sense to align the life spans of both the internal and external tokens so that they can be reissued together when they expire. Whenever these tokens need to be reissued, the OAuth authorization server will again be the component driving this. For better user experience, the mobile application will often want to avoid prompting the user for credentials. The OAuth standard accommodates this through the concept of refresh tokens but the internal token issuing pattern doesn’t always do that. For example, Kerberos-constrained delegation will let you get a new Kerberos token without the user’s password but other systems will not allow for that. This is often the source of motivation for storing the user credentials as part of the user session as mentioned above. You can instead allow for an internal token with a longer lifespan than the external token and reuse the existing internal token at OAuth refresh time.

Runtime Mapping
At runtime, the mobile application consumes an API on behalf of the user by calling the OAuth resource server, the runtime analog of the OAuth authorization server.

The OAuth resource server is the component responsible for validating an incoming OAuth access token. At runtime, the resource server can retrieve session information associated with the token presented by the application from the token management layer. The resource server will look at the scope and determine whether or not the API call should be authorized or not. When access control is completely assigned to the API Management infrastructure, the resource server makes all the authorization decisions, then passes the API call to the backend API endpoint but in this case, the backend API has its own authorization mechanism. To accommodate this mapping requirement, the resource server retrieves the internal token associated with the access token presented by the mobile application and injects it to the API call to the backend service.