printer friendly version

The do's and do nots of identity and access management

Many enterprises are planning or implementing identity access management projects. These initiatives are complex and expensive, requiring an approach that is both strategic and flexible.

Many enterprises are planning or implementing identity access management (IAM) projects. These initiatives are complex and expensive, and they require an approach that is both strategic and flexible. There are no hard-and-fast rules for successful IAM implementation – all enterprises must evaluate their own ability to follow specific practices – but Gartner has identified a set of high-level 'do’s and do nots' that can serve as best practices for most enterprises undertaking IAM projects.

Do’s

Do write small applications

Wherever possible, simplify authorisation complexity by writing applications as sets of components that are specific to particular application functions – for example, overriding a credit limit or approving medication for a patient with certain symptoms – so that authorisation decisions can be applied at a fine-grained level. This can be difficult to achieve and is much more practical for homegrown applications, but it allows for the externalisation and centralisation of authorisation policies, enhancing the management and reporting of user entitlements.

Do exploit centralised IAM architectures as much as possible for new and legacy applications

Legacy applications’ frequent requirements for operating system (OS)-level credentials – on mainframes, databases and other back-end platforms – represent a significant security concern. For this reason, you should, at a minimum, seek to centralise authentication to a Lightweight Directory Access Protocol (LDAP) repository. The ideal is to move toward a Web application portfolio that can be centrally managed by a Web access management (WAM) product, so look to replace or re-engineer ('Webify') legacy applications to exploit the product. New applications should be integrated directly with the WAM product.

Do use strong authentication

Mature solutions that can unify physical access, logical access (via smartcard) and ID badge in a single platform are now available to enterprises that require stronger authentication. Strong authentication tokens that can be used from any access point - inside or outside the network, online or offline - are also coming onto the market. These types of solutions offer increased security, greater user convenience and reduced password-management costs.

Do implement a centralised IAM event log repository

All IAM products must support enterprise compliance efforts, particularly with strong audit/compliance reporting functionality. To achieve this, all IAM event entries – authentication, authorisation and administration – should be held in one place. This dramatically reduces the labour required to produce needed IAM reports from weeks to days. All IAM products should export IAM event data in formats – for example, text, comma-separated values (CSV) and XML – that are easily consumable by security information and event management (SIEM) tools, rather than in proprietary formats. The SIEM tools should pull the data, rather than requiring the IAM vendors to push it to them, and should also correlate IAM event entries with other sources, such as directory services, application logs and OS logs.

Do create a cross-unit/cross-geography project with a senior-level commitment

IAM projects, especially those involving user provisioning, frequently force significant business-process changes and rationalisation across multiple business units and geographies. This can make IAM projects 'politically' difficult and expensive – and makes executive commitment essential.

Do engage a systems integrator (SI) for any large-scale project

Large-scale IAM projects (those with multiple business units and locations or more than 10 000 users) inevitably concern business processes more than technology, which makes experience a critical success factor. Enterprises with limited IAM project experience should rely on an SI that has been involved in past IAM projects. An enterprise that has personnel experienced in IAM initiatives (both process and technology) and requires assistance only with software installation can use the IAM vendor’s professional services groups as its only source of external support.

Do include audit costs when justifying an IAM investment

IAM solutions are expensive, with software license fees exceeding $250 000 for 5000-employee user-provisioning implementations. This investment can be partially justified by taking into account the cost of producing the reports required for regulatory compliance. Sharp reductions in the time, labour and cost required to produce these reports can help justify the investment in automation.

Do nots

Do not expect to use a single authoritative source of user information

Most enterprises rely on multiple sources of 'authoritative' information, including multiple human resources systems for employee profiles, e-mail systems for contact information and CRM applications for customer data. Expect 'political' difficulties and delays when selecting sources, both applications and personnel, for user information – and do not expect to be able to use a single source.

Do not aim for a single enterprise directory

Directory consolidation, though a viable goal, should not be pursued at the expense of organisational efficiency. Enterprises’ significant investments in applications, OSs, portals and other platforms frequently require the use of multiple directories. A given application may support only one directory that is not the enterprise choice, or converting from one directory product to another may simply be too expensive. In any case, most enterprises should, at a minimum, separate internal users from external users for performance and security purposes, because these groups represent different types of IT users and are often controlled by different business units.

Do not use your enterprise directory as the authoritative repository for user provisioning

The purpose of the enterprise directory (authenticating users to the network and beyond) is distinctly different from that of the authoritative repository for user provisioning (storing and reporting profile and access control information about each user). Combining authentication delivery with reporting delivery using a single repository will reduce performance for both. The authoritative repository can be a metadirectory, a virtual directory, a relational database management system or another repository separate from the enterprise directory.

Do not try to integrate all applications at once

Key success factors for an IAM project, in fact, virtually any IT project, are limiting complexity and identifying achievable goals. Gartner recommends selecting a small set of high-impact resources as initial targets, and creating a repeatable process integrated into both the IAM project life cycle and the application development life cycle/project life cycle process for integrating new resources associated with future projects. Begin with a 'friendly' department – one that is already interested in the benefits of the IAM project – and its associated applications, or start with an application that is widely used within the enterprise (for example, e-mail application or travel/expense reporting).

Do not expect enterprise single sign-on (ESSO) to work for every application

ESSO tools have greatly improved in terms of their ability to cover almost all applications, but there are still situations that may prevent an ESSO tool from providing the promised functionality. A portion of the enterprise’s application set may require a second authentication with a strong authentication device after an initial user ID and password authentication for the ESSO agent. Applications that use nonstandard Windows sign-on pop-up dialogues and terminal emulators that do not use standard application programming interfaces (APIs) and text prompts can also be difficult to integrate.

Do not aim for 100% user-to-role assignment

The cost of developing a role for every user is usually not worth the benefit. Some users will always require unique access, but they will be few enough to be managed acceptably as exceptions. When assigning user roles, begin with a high-level set of roles – for example, employee, nonemployee, manager, retired, alumnus or union member – to rapidly achieve automated provisioning, then develop more granular roles over time.

Do not worry about federated identity unless you can obtain immediate, obvious value from it

Federation technologies promise significant value to most enterprises over the long term, but federation capabilities should be a priority only if obvious value can be realised from it in the short term. One such enterprise would be one that must provide access to a large external user population (more than 10 000 members) controlled by a technically capable partner enterprise. Another would be an enterprise that is part of a 'coopetition' group that markets services to a large number of independent operators. A third would be a large, decentralised enterprise in which identity management (IdM) centralisation is impossible because of business or 'political' constraints.

Do not consider only tactical solutions to a tactical problem

Password management and ESSO products are 'point' solutions to acute tactical problems. By contrast, user provisioning and WAM systems offer strategic simplification of the enterprise IdM function, but may provide significant reduction of tactical problems as well, for example, through reduced sign-on and automated password management. When trying to solve a tactical problem, it may be best to look beyond the point solution and consider a strategic solution that solves more problems for the enterprise. This does not mean that focused password management and ESSO tools do not have value. There are many situations where they make the best fit, either alone and implemented in tandem with a user-provisioning system.

Do not write your own comprehensive IAM system unless your needs are, and will remain, simple

In the past, some enterprises decided to develop their own centralised IdM or WAM systems, because products in these areas were either nonexistent or incapable of addressing their business requirements. This is no longer the case. Mature products are now available from focused, well-supported and experienced technology providers, and few enterprises are capable of expending the resources necessary to create such functionality. The few exceptions are enterprises with relatively simple identity provisioning requirements.

The Do’s and Don’ts of Identity and Access Management by Ray Wagner, Roberta J. Witty, John Enck, Gregg Kreizman (Gartner RAS Core Research Note G00138225, available at http://mediaproducts.gartner.com/reprints/ca/138225.html) was published with permission from Gartner.

Share this article:

Further reading: