Three Approaches To Cloud Identity Management

Write Your Own Cloud Identity System

Probably the most common approach to developing identity infrastructure for cloud applications is to build something yourself. Using a combination of custom code and freely available open-source components it is possible to build a basic functioning identity system fairly quickly. However, such identity solutions rarely work well in the longer term for a number of reasons.

Firstly, you must build your cloud identity system so it will scale as your user base grows. Identity systems are by nature very read-heavy, generating several hundred times the number of read operations as write operations. (Think of the number of times you login compared to the number of times you update your details.) And identity updates are usually very localized, requiring at most the update of one or two objects. SQL databases and the object-relational mappers (ORMs) used by many web application platforms are optimized for an entirely different kind of workload, where many rows in many updates are updated together in a single transaction. Configuring and managing the SQL partitioning and replication so that your application can reliably and efficiently serve a global audience is also highly specialized knowledge.

Second, cloud identity technology itself is complex. Implementing even basic username and password authentication properly requires specialist knowledge. Get it wrong and your applications are left vulnerable to bugs, the inadvertent disclosure of potentially sensitive information or even the theft of your data

And finally, identity requirements change as applications mature. The first version of your cloud application might only need a username, password and email address. However, version two might require links to social media, profile and preference information, contact details, roles and relationships with other identities and for version three you might want role-based access control to resources and user-based consent to personal details. Redesigning your identity system every time you have a new requirement is expensive and prone to error. On the other hand, trying to design an identity system that can accommodate all possible future requirements will most likely result in over-elaborate and extraneous code that you must test and maintain. And every time you add a new feature to your application, you must modify your identity system to support the appropriate authorization policies for that feature.

So, although it is fairly easy to use your application platform to build a rudimentary identity system, building an identity system that will evolve and grow to support your changing application requirements is a substantial investment, and a substantial risk.

Use a Cloud-based Identity Service

An alternative approach to providing identity infrastructure for your applications is to use a cloud-based identity service. There are a number of different service providers out there including the big cloud application development platforms such as Microsoft’s Azure Active Directory, Google, and Salesforce and smaller specialist identity as a service (IDaaS) providers like Okta, Ping, and Onelogin.

Using a hosted service has a number of advantages over building your own identity system. Such services are generally well designed and implemented, they support common identity standards, provide a robust, reliable and scalable service and they are ‘just there’. You don’t have to manage any additional cloud infrastructure to support your application’s identity needs.

However, there are some significant downsides to using such service providers. First, you lose control of your identity information. Instead of storing sensitive identity data on servers that you control and administer, you store it on servers controlled by a third party. This might not be a big deal. The public identity services may very well have stronger security controls and administration processes than you do. But your legal or security requirements may prohibit letting sensitive identity information out of your control, or allowing it to be handled by a foreign enterprise subject to a foreign government’s privacy and disclosure rules.

Another potential problem with public cloud identity services is their relative inflexibility. These providers have created infrastructure capable of supporting identity on a large scale, but they have traded off features and configurability that might be important for your applications. For instance, some identity services provide only a fixed identity schema. If you need to store additional attributes with your identity data, you must implement your own parallel identity store.

However, the real problem with committing to a public identity service is vendor lock-in. Once you have stored all your identity data with a particular service and written your applications to work with the particular features and quirks of that vendor’s system, it will be very difficult to move your application to a different identity infrastructure. You have effectively locked your applications to the vendor’s identity infrastructure and you will be subject to whatever service, feature, and cost changes that vendor decides to make in the future. So, while you enjoyed agility at the start of your project by leveraging an existing service, you have basically given up that agility for the life of your application.

Use Packaged Identity Software

The final approach to providing the identity infrastructure for your applications is to use packaged cloud identity software. This is essentially an extension of the software model used with Active Directory for on-premises identity. You must provide the hardware (virtualized or otherwise) and operations manpower but the software itself is complete and ready to deploy after some basic configuration.

The packaged software approach has a couple of disadvantages. It requires setup and configuration on your part, so it is not ‘just there’ like a public identity service. Depending on the cloud software package you choose, this might be a significant effort or not. Although once you have worked it out, your cloud automation software can handle subsequent installations. Then there are the ongoing operational costs. Not only do you have to manage your cloud applications, you also have to manage the identity software as well. Although once again, this can be largely automated, so the incremental costs should be small.

On the other hand, there are several substantial advantages to using packaged software for your cloud identity needs. You get a richer feature set and more configuration flexibility. So, instead of having to shoehorn your application identity into a one-size-fits-all identity data model, you can tailor your data model to suit your needs. And you remain in control of your identity data. You control where it lives, how it is managed, and how it is accessed. This means that you can be sure that your identity data is secured according to your requirements, not according to those of a third-party or foreign government. Finally, and most importantly, you are not locked into a service providers feature set or pricing model.

Conclusions

Cloud identity management is a totally different beast than on-premises identity management and the software you need to create your application’s identity infrastructure has to be designed and built with cloud requirements in mind. Building your own cloud identity infrastructure is almost never a good idea. It is far safer and more efficient to let your application developers focus on the features of your application and to leverage the expertise of identity specialists for your identity infrastructure.

Taking advantage of a cloud identity service can be an effective approach, particularly when you are just starting out, but has significant downsides in terms of control, flexibility and vendor lock-in. Using packaged identity software for your cloud application’s identity needs does require that you deploy and manage the identity software along with your cloud application, but has several significant benefits including a richer feature set and increased control over your identity data, as well as the fact that you are never locked-in to a third-party’s pricing model.