The 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.
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.
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.