Seven Reasons Why Cloud Identity is Different
Over the past 20 years we have learned how to architect and manage identity and access management for our on-premises applications. And what is the most important lesson we have learnt? That identity and access management cannot be left to the application but must be centralized in a system designed and securely built for that purpose. Although identity and access functions in the cloud are the same – directory, authentication, authorization, and audit – the mechanisms are entirely new.
Here are 7 reasons why cloud identity is different:
1. Accessibility
Probably the most important motivation for moving applications to the cloud is to make them more accessible to people outside the corporate firewall and outside the company. Expanding the reach of an application to new user populations requires rethinking the conventional on-premises approach to identity.
On-premises identity services exist to provide strict control over access to applications inside the corporate firewall. In the typical on-premises environment a new user has to go through several steps to use an application. First, the IT department creates an account in Active Directory (and possibly other systems). Then the user gets approval to use the application. After that, IT adds the user to the appropriate groups and maybe even installs the software on the user’s computer. All these steps ensure that IT maintains control over who can use the application.
The purpose of cloud-based identity systems is more or less the opposite. They traverse network and security boundaries, integrate with external identity systems and make the application easily available to people inside and outside the organization, all with little or no input from IT. Users can sign up for the application using just their email address and use a social network identity (such as Facebook or Twitter) to authenticate. In the cloud, users define and control access to their own identity information. IT is not involved.
2. Scalability And Performance
Scalability and performance requirements are very different in cloud applications. Some cloud identity systems (such as Facebook) handle billions of user accounts. Other cloud identity systems (like Azure Active Directory) provide hundreds of millions of authentication transactions per day. This is sort of scale is not the norm for on-premises identity systems and handling it requires careful attention to product architecture.
3. Efficiency
Related to scalability and performance is efficiency. Almost all Active Directory systems use dedicated servers as domain controllers, for both security and administrative reasons. So, once you have purchased a server, there are essentially no ongoing costs. Whether that domain controller uses 10% of the CPU and 5GB of RAM or 80% of the CPU and 10GB of RAM makes no difference to your bottom line. Purchasing virtual machines in the cloud is different. Because you are paying more per month the more computing resources you use, the efficiency of your cloud identity system actually affects your monthly bill.
4. API Support
Cloud-based identity systems need to support a different set of application programming interfaces (APIs) than their on-premises counterparts. On-premises identity systems, like Active Directory, use LDAP for directory access and Kerberos for authentication and authorization. However, the cloud environment requires protocols that are stateless, can recover from connection failures seamlessly and can traverse firewalls and load balancers with no additional configuration. So, cloud APIs are based on HTTP/S and use a Representational State Transfer (REST)-ful model. Consequently there are a new set of identity protocols based on HTTP/S that provide equivalent identity functions to on-premises systems: OData and SCIM for directory access, OpenID Connect for authentication, and OAuth 2 and the XACML 3.0 REST/JSON profile for externalized authorization.
5. Multi-tenancy
The concept of multi-tenancy is the ability to segregate sets of identity data from each other, usually along organizational lines (think of a cloud service with multiple enterprise customers, something like SalesForce). This concept is not required in on-premises enterprise identity systems because they are inherently single tenant solutions. But cloud service providers have to maintain strict separation of the identities associated with their different enterprise customers, so cloud identity systems must be able to support that.
6. Identity Data Model
The cloud identity data model for applications is often more complex than that of a typical on-premises identity system. The on-premises model is generally pretty straightforward: there are some organizational structures (for example OUs in the directory) that represent different business units or departments, there are users and computers whose lifecycle is controlled by IT, and there are groups (possibly nested) that enumerate users with certain rights. And that is pretty much it. Whereas, cloud identity systems, particularly consumer-facing or externally-facing cloud identity systems, must model a more complicated ecosystem of identity information including users, organizations or tenants (and possibly tenants of tenants), a sophisticated relationship of applications, roles, and permissions, and trust relationships with external identity providers and consumers. Add on top of that the notion of social identity, for instance which products does the user like, which users like the same product, etc. and you can see that the cloud identity model is pretty complex.
7. Security And Privacy
Finally there are the security and privacy issues. If you are a cloud service provider maintaining identity information for your customers or an enterprise storing identity data for your corporate employees and partner organizations, then you have the moral and legal responsibility to maintain that data securely. But at the same time you want to give your users maximum flexibility in defining who can access that information and under what circumstances. It goes without saying that passwords should be hashed and encrypted before being stored on disk, but so should other personal information like social security numbers, credit card and bank details. In addition, the identity software you use has to be bullet-proof to prevent hackers from compromising your system, your users’ personal information, and potentially external systems as well.
Even though cloud identity systems have to provide the same basic functions (identity, authentication, authorization, and audit) as their on-premises counterparts, cloud identity really is quite different.