As we'll discuss in our review, getting the software up and running is only a small part of the battle. Without exception, the vendors visiting our Real-World Labs® told us that defining policies and integrating distinct identity stores take much longer. For example, a typical enterprise with several data repositories must set policies that define which repository is the authority and how identity information is shared among repositories. Policies may be based on something simple, such as a departmental unit, or may be dynamic, as with policies based on data from several data stores. Roles and/or functions also must be created. Role-based access control simplifies the management of thousands of users by assigning them access to resources based on policies. If users don't fit exactly into a defined role, the organization can grant access to specific functions (function-based access control), which allows for more granular access but increases system overhead.
Planning also involves deciding which resources should be protected, and to what extent a compromised resource would adversely affect the organization. This decision-making process will help determine the level of authentication needed to access the resource--for example, in addition to user names and passwords, all the products we tested support tokens, smartcards, X.509 certificates, federated identity and biometrics. Once such a determination is made, then and only then should ACLs and policies be set up by the IT manager or delegated owner of the resource. Yes, it's a lot of work, but the payoff in added efficiency, security and customization capabilities will help IT make a real contribution to business goals.
Jeffrey H. Rubin is a senior instructor with the School of Information Studies at Syracuse University and president of Internet Consulting Services. Send your comments on this article to [email protected].
"Identity Management, Authentication Take the Spotlight at RSA,"