By Stephen J. Bigelow, Senior Technology Writer
Identity management (IdM) can present serious deployment challenges for solution providers. While the technologies aren't difficult to install, the setup and configuration varies for each client. This requires you to understand the unique business needs of the client, plan the configuration in advance, and be ready to refine the setup after deployment. The first part of this Hot Spot Tutorial presented an overview of identity management, its objectives and features, and some of the technical requirements involved. This second installment looks more closely at deployment considerations, examines identity management best practices and highlights business opportunities for solution providers.
Pre-assessment and planning considerations for identity management
"Identity management is a difficult thing to do," said Andrew Plato, president of Anitian Enterprise Security, a security solution provider located in Beaverton, Ore. "It's something that has a lot of complexity to it and requires a lot of integration into the oddities of an organization." The unique needs of client businesses make it difficult to field full-featured appliances for identity management. Instead, an identity management engine and supporting software (e.g., Web interfaces, reporting and workflow tools) are often deployed across two or more servers. The servers and software are easy to implement but difficult to configure, making predeployment assessment and planning vital for both the solution provider and the client.
There are two core predeployment challenges: unexpected changes and future migration. Unexpected changes occur when the IdM system doesn't properly accommodate current user rights or accounts. This happens during the initial planning and deployment. "The system that you're putting in is messing with live user accounts," said Jim Gerken, senior practice manager in charge of identity management at Novacoast, an IT professional services and product development company headquartered in Santa Barbara, Calif. To avoid this problem, Gerken recommends first deploying the IdM system into a development environment where it can be tested and refined before rolling it out to live users.
"You can't make an identity management error and not have it be noticed," Gerken said. Common IdM errors can include incorrect or incomplete rights assignments, or accounts locking out because they no longer comply with policies. Be familiar with the current user, employee or partner identities and then consider the scope of identities that should exist once the project is complete.
Solution providers must also contend with user data migration and reconciliation. The client has live user access data (and possibly some form of rules and policies) already in place. The challenge is to understand and plan the proper translation of existing identity management data into the newly deployed environment. "You're usually developing a solution for a set of future rules -- the way that the system 'should' work from here on out," Gerken said, noting that even something as simple as a new password policy or a new login naming convention may conflict with existing user logon data and mushroom into a support nightmare. Understand how to handle the users that may no longer be in compliance with the new IdM system. "Be careful, when you deploy it, how you reconcile what was with what will be," Gerken said.
Regulatory compliance and corporate governance both affect identity management best practices, and must be considered during pre-assessment and planning. Clients that aren't currently driven by compliance will likely be concerned with it in the near future; even large partners may compel the client to meet compliance regulations. "Identity is becoming such a key component and so very visible in both the security and compliance arenas that the customer is best suited by doing it that way," Gerken said, also pointing out that there is little legal precedent that determines fault in the event of a breach, particularly if the solution provider fails to consider compliance issues in their design or implementation.
Configuration can overwhelm less experienced solution providers, leading to an IdM platform that isn't deployed to its fullest potential. Identity management implementation is not the place for solution providers to cut corners -- it's critical to configure the IdM system comprehensively from the start to ensure that the client's long-term objectives are met. Ask for help as needed from vendors and other colleagues.
Identity lifecycle management and phased IdM deployment
Identity management projects involve more than successful deployment, and solution providers should embrace the notion of identity lifecycle management (ILM -- not to be confused with information lifecycle management which is also dubbed ILM). IdM is based on an "identity" that brings together all of the facets that define someone's accounts, access and rights throughout the organization. Facets may include application permissions, user names and passwords, a permanent record in human resources, an electronic badge or smartcard, an email account, public key infrastructure (PKI) or other security certificates.
Once an identity is established, it is hardly static. For example, an identity is created for a new employee that includes certain basic rights. The employee gains additional duties and requires more access to a larger scope of applications. That identity must then be destroyed when the employee leaves the organization. Every identity follows a lifecycle, and the client's IdM platform should accommodate the changes and eventual closure of that identity. Tools like Microsoft's Identity Lifecycle Manager 2007 offer identity synchronization, certificate management and provisioning/deprovisioning capabilities that allow administrators to manage more elements of an identity with a single product.
A client's identity management architecture can be just as dynamic as the identities it handles. As with most major business initiatives, identity management is rarely a one-time project. Deployment takes place in phases, systematically embracing more elements of the client's business. "You start off small, and then it needs to grow and encompass everything in the environment," Gerken said. "Unless you're starting a new company, you're not going to be able to put identity management in for everything immediately." In many cases, solution providers will develop a phased deployment roadmap that starts with noncritical elements of user identity and rights, then gradually build out the deployment as the client starts to see value in the technology.
The evolution of your client's business must factor into deployment plans. Even after identity management best practices are fully implemented, new applications and compliance initiatives will inevitably appear. Solution providers should help the client map the identity management system to any new requirements.
Channel opportunities for identity management
Identity management best practice initiatives can drive a wide range of revenue opportunities for solution providers. Pre-assessment consulting is one opportunity, identifying the potential benefits of IdM in your client's organization and evaluating the technical challenges present in the current infrastructure. Implementation is also a common revenue source, and the associated product sales can be surprisingly strong. "Identity management products are not commoditized yet, so selling products is good; there's money to be made there," Gerken said.
Each phase of IdM deployment is a revenue opportunity. IdM software updates and maintenance (such as patches or new versions) are excellent opportunities to re-examine client needs and business goals. This is particularly important when the client adds new applications or acquires other companies that must be integrated into the existing identity management scheme.
Experts like Gerken and Plato are split on the viability of IdM management as an outsourced service handled by a solution provider. Identity management is often deployed across the client's organization, making it difficult for any one group to take ownership. "People don't have a place to put identity management staff, so they don't get an identity management staff," Gerken said. "So there's managed services -- making sure the service stays up, patching it and so on." In contrast, Plato sees IdM platforms as an internally managed resource, and doesn't find outside management to be a viable opportunity. Solution providers will need to consider the capabilities of each client and pitch services on a case-by-case basis.
Some solution providers may find revenue opportunities in training customers on higher-end IdM concepts. "All of the vendors do a good job of training on their particular products," Gerken said. "But nobody trains on the ideas of the business and the compliance and how to map the tools to the business rules." Another training opportunity is to bring the client's end users up to speed on the Web portals or other user-facing self-service tools present in an IdM deployment.
Experts like Gerken and Plato point out that identity management can affect many elements of the client's infrastructure, opening many supplemental opportunities for you to pursue. "Identity management projects will tend to spawn a lot of change in the client's organization," Plato said. "Anytime there's change, that's an opportunity for solution providers to move in." Even solution providers that don't win a bid for IdM directly can still find work augmenting network security, firewalls, remote access, encryption, integrating smart cards, updating workflow or other business processes to accommodate compliance requirements, and many other ancillary tasks related to identity management best practices.