IAM projects are complex, encompassing most IT infrastructure, and can take years to fully implement and roll out. So trying to do everything at once is a recipe for failure. So we turn our discussion to how to deploy IAM without biting off more than you can chew. We will discuss how to approach building an architectural schema for your particular organization, based on the cloud service and deployment models you have selected. Then we will create different implementation roadmaps depending your project goals and most critical business requirements.

The last post described three common use cases for Cloud IAM: Single Sign On, Provisioning, and Attribute Exchange. The good news is that the process of creating a deployment roadmap is largely the same, regardless of which use case you choose. But every customer’s environment and priorities are different, so delivering on these use cases requires a slightly different implementation and project plan for every customer.

Implementation roadmaps start with a system design, and then describe the series of steps needed to deploy the solution in phases. The roadmap should begin with the assumption that there will be a lot of catch-up to play, because most organizations do not have a cohesive identity strategy. In fact there is rarely a dedicated identity team, much less a VP-level position supporting IAM as a critical function. It is mainly an exercise left to unlucky souls who zigged when they should have zagged, and as a reward got the title “IAM Architect” tacked onto their existing laundry list of responsibilities. These people, overwhelmed by complexity, punt and outsource the problem to consultants. The predictable result is a patchwork of partially implemented tactical solutions.

We started this post in Debbie Downer mode because a) you are unlikely to successfully solve the problem without appreciating its magnitude, and b) your plans need to take the current state of IAM in your company into account. With these considerations in mind you can realistically decide which problems to address first – taking into account the available organizational, process, and technology support. Try not to think of Cloud IAM as yet another point IAM solution. The total rethink of IAM prompted by cloud computing offers more flexible and effective solutions than have been available over the last decade. So we urge you to adjust your thinking, consider where identity solutions will be useful, and figure out how one of the cloud architectures we have described can extend your capabilities.

Let’s drill into the use cases and focus specifically on the ‘actor’ roles, mapping how these actors interact with one another. We touched on several common roles – Identity Provider, Relying Party, Attribute Provider, Authoritative Source, and Policy Decision Point. A good first step in outlining your strategy is figuring out which servers will fill these roles. Second, determine how the parties will communicate and what information they need to exchange. This process map should provide a good understanding of how all the pieces work together, which feature will be important, and what data needs to be available. Your map should include constraints imposed by these system actors – for example, the cloud application Relying Party likely accepts a limited set of identity tokens. Understanding limitations early is just as important as knowing what the feature requirements are.

Communications are often taken for granted. It’s that Internet / cloud thing, so it must all be HTTP, right? Well, mostly, but not always. It could be API calls, or HTTP communications might rely on supplementary SSL/TLS for security. To avoid surprises and last minute fire drills over firewall rule changes, trace out the necessary end-to-end communications and protocols. Often there are requirements for non-HTTP protocols buried deep beneath the surface – this is particularly common for provisioning. Security issues crop up due to information leakage, session security, spoofing, and other concerns, so it pays to examine the dialogue between parties and specify secure communications during the design phase.

As we alluded earlier, the state of play in IAM is frequently a hodgepodge of stuff, with various components bolted on to solve specific problems that popped up at various times. This forces some IAM projects to burn considerable calendar time on data cleanup and transformation. Again, the starting point is a schema for identity and accounts used for cloud access decisions. It is critical to understand what work needs to be performed, and to identify the most difficult integrations.

From there the order of implementation is heavily influenced by how much of a mess you need to clean up. We caution that simple is best – do not try to build a be-all end-all uber-identity-schema. Even if schema definition is straightforward, enforcing it across multiple backends rarely is. It is important to review data sources, ensure they work with the identity schema, and establish a process for cleaning up and dealing with conflicts. Realistic expectations are your friend – be conservative about what can be achieved, and don’t get too aggressive out of the gate. Do not copy your feature list from a vendor’s capabilities document and assume everything will “just work”. Be conservative; less is more.

One final word on building your schema: You need to understand not only how things work, but also what happens when they don’t work. Identity and access have ugly failure modes; when they break people notice and you will get the blame. Plan for failures at each node within your schema, and understand the side effects when each service goes down; are there interesting complications if two go down at the same time, or in the worst possible sequence? Can your system withstand periodic brief outages? You need to conduct sufficient testing to discover issues before production deployment. But most security and QA tools are not well suited to testing IAM. So for each use case you deploy, build out a set of test cases (both positive: this should work, and negative: this should fail) to ensure that what you are promoting works end-to-end. These tests may influence your deployment timeline as problems are discovered – better now than when (or after) moving the system into production; most users don’t care about your technical issues – they just need this stuff to work.

Operational planning should also include building a runbook: the set of installation, configuration, logging, and administrative tasks needed to keep the IAM system running. For cloud apps this requires careful planning and coordination because some roles and responsibilities are new, and roles are shared between cloud vendors and the enterprise. You need to understand which roles you manage, and which are handled by your cloud service provider. For some cloud deployments (IaaS, private cloud, and some PaaS) you can configure the infrastructure to ensure logging, system configuration, and administrator roles are fully defined prior to launching any instances. With SaaS and IDaaS you need verification from your cloud vendor.