Understanding Cloud IAM: Buyers GuideBy Adrian Lane
With our last post in this series on Understanding and Selecting Cloud Identity and Access Management, we want to help guide you through product selection. No two customer environments or lists of requirements are the same, but key decision criteria will help you narrow down the field to suitable platforms. We will provide questions to help determine which vendors offer solutions that fit your architecture, a set of criteria to measure the appropriateness of a vendor solution to your design goals, and help walk you through the evaluation process.
Your mileage WILL vary
Spoiler alert – there’s no such thing as plain vanilla IAM. You may need a solution for customers as well as users. You may or may not need to include mobile devices. You may need fine-grained authorization controls for external applications. There are far too many variables in play for IAM evaluation to be fully quantifiable. But to help you weed out some players, to align your needs with product function, and to give you a handle on major product differentiators, we created the table below. You need to make sure products match your goals. Even IAM suites that can do everything on paper have their own strengths and weaknesses, so make sure you know them before leaping in.
As we have discussed, prospective buyers should start with understanding their use cases and governance processes before analyzing the IAM marketplace. That said, here is a proposed checklist for beginning to analyze IAM products:
|Product Architecture||What are the product’s key capabilities?|
|What are the internal data models and formats for identity?|
|What are the external data models and formats for identity?|
|How does the product scale, vertically or horizontally?|
|Development||What is the development interface for implementing and extending the product?|
|Is development typically performed by the company or third party consultants? Answer for both development and maintenance phases.|
|What integration is available for source code and configuration management?|
|What languages and tools are required to extend the product by with wrappers, adapters, and extensions?|
|Interoperability||What IAM standards are supported and where are they available in the product? What interfaces are standards based and what are proprietary?|
|What directories are supported – Active Directory, LDAP …?|
|What application servers are supported – Websphere, IIS, Tomcat, SAP …?|
|Are cloud applications supported? Which ones?|
|Are mobile platforms supported? Which ones?|
|Product Security||What is the product security model?|
|Is Role-Based Access Control supported? Where?|
|How is access audited?|
|Use Case Support||Describe the product’s support for provisioning uses|
|Describe the product’s support for Singe Sign On uses|
|Describe the product’s support for attribute exchange use cases|
|What user self-service capabilities does the product support?|
|Cost Model||How is the product licensed?|
|Does cost scale based on number of users, number of servers, or something else?|
|What is the charge for adapters and extensions?|
This checklist provides a starting point for analyzing IAM products. As the evaluation unfolds, it is key to remember what matters: integration, standards, and cost. The buying process works much better if the initial step includes an inventory of IAM sources and targets: where identity is used, and what the authoritative sources are. What IAM processes exist currently, and which and are desired in future?
Securosis highly recommends a Proof-of-Concept (POC) as a final step for IAM buyers. PowerPoint does not crash much, but new implementations do. There is nothing like seeing a product working in your own environment.
If there is more than one vendor in play – and there usually is – then bake-offs can be useful to determine the best fit. But we generally do not recommend bake-offs with more than two vendors. Many vendors take widely different conceptual approaches to IAM problems, and in-depth evaluations are too demanding to perform more than once or twice. Start with an initial review, against our checklist, to weed out unsuitable candidates. Then use a proof of concept to test viability and/or a bake-off to compare a couple similar candidates.