Identity Management as a Service (IDaaS) could provide a level of benefit to an organization when it comes to things like account management for an enterprise's SaaS partners, but in the short-term, identity management services are still best when managed internally. Why? It really comes down to two factors: Identity management represents the keys to the kingdom, so to speak, and IDaaS vendors don't take on the risk associated with losing crucial identity information.
Identity management is a control function at heart; whether managing short-term access to applications and services or long-term lifecycle management of user identities, you're implementing a double deployment scheme. You're integrating a number of identity management tool sets (i.e. provisioning systems, meta-directories, Web access management systems, repositories, etc.) from several vendors -- not to be confused with an integrated set of tools such as an identity management product suite from a single vendor (which isn't implemented often because there isn't a single vendor whose entire suite of products is considered best-in-class) -- and then integrating these into your business systems.
This integration not only requires ongoing and intimate knowledge of the computing environment, but it also requires a large amount of political collateral to ensure that business managers trust you to manage a key function of their systems. While some SaaS services, like external mail providers, can integrate their authentication services with your enterprise directory, they don't have the ability, or desire, to be responsible for managing this information for the rest of your applications. In addition, it's known that years ago, when IAM expertise was still hard to find, many enterprises that contracted out their identity management systems pulled them back in when they realized the companies they outsourced to had obtained the authority to issue accounts for the enterprise's sensitive business systems. Suddenly a strategy that was meant to increase efficiency became a compromise of security.
But regardless, if you're still considering IDaaS, you should ask the following questions:
What is the third party's ability to support your workflow and process needs? Can it meet your assurance and audit requirements? How agile is it when it comes to scalability and adding new functionality? Does its contract's terms and conditions meet your needs, or will you be taking on additional risk? What does it monitor and report to you? What are its mitigation and notification processes in the unlikely event that it has a breach or an incident while handling your information? If and when you decide to disengage from this third party, what are its procedures for disengagement, and what does it do with your company's backups and stored data that it has on its systems?
Moving the support for identity management out of your domain requires a lot of planning, architecture and bravery. Ensure you have all three before bringing an IDaaS vendor through the door.
For more information:
This was first published in September 2009