January 14, 2015 Leave a Comment
Avatar
Inside Cisco IT

To the Cloud: Why We’ve Moved to an API-Based Architecture – Part 2: Identity as a Service

This is part 2 in a 2-part series about our API-based architecture. Part 1 explains how we provide content as a service to sellers.

Federated identity is central to cloud computing. You can’t have a useful hybrid cloud service without it. 

Here’s why: Imagine logging into an application that connects to multiple clouds. How would you feel about having to log in again every time you used a feature based on a cloud service? An example is Cisco IT’s SalesConnect application, which provides personalized content recommendations to sellers. SalesConnect connects to several clouds, including Salesforce and the portal where partners register their sales opportunities. If we made users sign into each cloud, they wouldn’t use SalesConnect. It’s as simple as that.

We took a step toward federated identity when we implemented single sign on a few years ago. But single sign on isn’t enough in an intercloud environment. For intercloud services to be useful, the various cloud applications need to be able to trust each other to authenticate and authorize users.

Identity as a Service
That’s why a shared authentication and authorization layer is part of our new API-based architecture. SalesConnect is the first platform to use the layer, connecting to it using REST APIs. Cisco Enterprise Policy Manager applies access policy based on the user’s role—for example, buyer, seller, or service provider.

When role-based authorization is fully implemented, every Cisco application will connect to the authorization layer to look for the user’s employer and role. This will help us provide a consistent, personalized user experience on mobile and web applications. We’ll also be able to consistently control access to applications that connect to one or more clouds, like SalesConnect.

Four Benefits to a Shared Identity Layer

Taking an architectural approach to identity services benefits us in these ways:

  1. Better user experience.
  2. Less time and cost for application development: Our developers don’t need to write code for authorizing users. Instead, applications only need a small amount of code to manage entitlements, or privileges. For example, a return merchandise authorization (RMA) application for Cisco partners would need to validate whether the partner was entitled to overnight shipment.
  3. Better governance for protecting data: Instead of managing access in every application, we can manage it centrally, in the identity layer. We’ll use Cisco Enterprise Policy Manager. Applying access policies in one place is more secure.
  4. Less time to add new products to seller applications: In the past, we had to specify who could access information about new products. We had to do this in every seller application, including pre-sales applications, Salesforce, and the Technical Assistance Center (TAC). Moving from application-based access policies to role-based access policies shrank the time to update seller applications by more than half, from 2-3 quarters to 1 quarter.

For More Information