Implementation Problems and Pitfalls

Let us be very clear: any program related to identity and access management belongs under the ownership of the information security department—not the IT engineers, not the IT architects, not HR, not the directory services team. User management is inherently a security function and must therefore be driven by the security strategy. However, an identity and access management solution truly touches every system and every user in the enterprise. Therefore, collaboration and participation will be required from most or all other IT teams, HR, and most or all business units.

It will therefore be crucial to obtain buy-in and representation from a very large audience. In particular, participation is needed from other departments to get a clear and detailed understanding of how user management works today, to help you determine what needs to happen to streamline it. You also need to ensure that you select a solution that will effectively interoperate with the rest of your infrastructure because the technology components of a user management system will be embedded so deeply into your company's architecture.

The following subsections discuss some considerations and problems in implementing a user management solution.

Multiple-User Stores

Many companies, whether through the process of acquisition or as a result of being decentralized regionally, have more than one HR system. Even worse, a lot of companies do not have a centralized repository (or any repository, really) for keeping track of nonemployees such as temps and contractors. As a result, it is very difficult to determine accurately what has happened to a user. For example, most companies with two or more HR systems handle users that transfer between systems as a termination in the old system and a new hire in the new system. From an access perspective, that user should not be terminated, although his or her privileges may need to change. Therefore, if you rely on reports from your HR systems to inform you about who has left the company, and you are unable to correlate a termination in one system with a new hire in another, you may inappropriately terminate a valid user. Conversely, if you have no accurate way of tracking the comings and goings of your nonemployee users, you could be left with active IDs that have not had valid owners for a very long time.

Even if you do have several accurate stores, correlation could still be a challenge and will always leave room for error in an area where error is not well tolerated. Although it is outside the scope of an identity and access management program per se, it is strongly recommended that, as part of this effort, you consider consolidating your user stores into (ideally) one, or at most two (one for employees, one for nonemployees). This will ensure the most accurate view of information and will also make it easier to synchronize that information with other relevant sources, such as your directory and your provisioning tool. If you need to maintain users manually for a while longer, it will save your team a lot of time and effort in trying to correlate information and research the exact status of users so they can go about the job of simply keeping accounts clean.

Clearly, the effort to consolidate HR databases or create nonemployee repositories is a significant undertaking that must have the buy-in of the HR department and executive management. Information security can add value to this initiative by raising it as a requirement. Many HR organizations would like to undertake projects of this nature, but have not had sufficient reason to justify the budget and resources required. By throwing the information security hat into the ring and demonstrating how database consolidation and nonemployee tracking can reduce the costs of implementing an identity and access management system—as well as make the company more compliant for audit purposes—you may be able to help HR tip the scales in its favor and get funding approved.

Inadequate User Information

Whether your HR stores are consolidated or distributed, you may also have the additional problem of inadequate or inaccurate user information. Inadequate information really stems from the use of an HR system versus the needs of a user management program. From an HR perspective, it is sufficient to know a person's grade, job title, department, and manager to train and pay him or her. From a user management perspective, that manager could lead several functions and, even though the people under him or her have the same HR title, they may actually require different system permissions. Also, HR systems typically do not store user IDs because HR uses other identifiers such as employee number or Social Security number. This can cause problems for users with common names if there is a disconnect between their HR records and their user IDs.

For example, suppose a user is registered in the HR database as Thomas Smith, but his ID is created as tom.smith because he commonly goes by Tom. There is also a Tom Smith registered in the HR database. How do you determine to whom the ID tom.smith belongs? If you do not even have synchrony of user IDs across systems, the problem becomes even more dire. A company once had three users with last name Nguyen, and first initial H. The company's user ID format was first initial plus last name. A digit was appended at the end to avoid duplicates. The three users had IDs of hnguyen, hnguyen1, and hnguyen2. However, their IDs were not synchronized across systems, so they were each hnguyen in some places, hnguyen1 in other places, and hnguyen2 in still other places. It was impossible to distinguish who owned which ID on any given system without physically contacting the users and asking (and hoping they remembered accurately). To make matters worse, in the HR system, they all showed as being part of the same department (IT).

The conclusion that most companies reach is that the full user store must reside in the directory. The directory must be carefully architected to pull various bits of information from the appropriate system of record and be updated frequently enough to keep it accurate, while not bringing down the network or other systems. The directory should also have the authority to populate other systems with information from the system of record. For example, there are a variety of reasons why you might want to have the HR database store a user's ID. The directory could receive this information from the authoritative source (in this case, the user provisioning tool) and pass it on to the HR database. However, the directory would need to be configured never to populate user IDs from HR back into the user provisioning tool. Similarly, relevant user information from HR would be propagated to the user provisioning tool, to assist the tool in determining the appropriate role to assign or rules to apply.

The directory might be the authoritative source for still more information. Users may use the directory as an input mechanism to update their mobile phone number or home address. This information would get propagated to HR. For user management to be accurate and sufficiently granular, it is necessary for data from all of these sources, and possibly others, to be amassed in a single location and accessible on demand.

Similar to the HR consolidation project, architecting an adequate directory structure will require the buy-in and participation of your directory services department, as well as from HR and other groups that may be required to interface with the directory to provide or obtain information. A sound directory structure is the foundation of the identity and access management enterprise. If your directory is not clean, accurate, and thoroughly populated or if it is inadequately secured to protect this wealth of information, it does not make any sense to build additional components. Address the issues with your directory first.

Incorrect User Information

Incorrect information about a user is perhaps more damaging than lack of information. If you are basing access decisions for a user based on data from two years ago, you have a problem. This is again a mandatory cleanup project that is a prerequisite to the main identity and access management program and is the responsibility of the departments owning the systems of record. Maintaining accurate data is largely a procedural concern. Work with HR (or other departments as needed) to develop efficient processes for keeping data up to date. You may also need to retrain personnel in the use of certain system fields. If you need to transfer data from one system to another, the receiving system will expect a certain format. If someone has input data into that field that is not in the expected format, the data transfer will fail.

The problem of outdated information is of course much more prevalent in large companies, where it is not trivial to track the intradepartmental or even interdepartmental movements of individuals accurately. One effective solution to this is to build a workflow mechanism that is driven by HR. On a monthly basis an automated process could run against the HR databases and generate a listing of all users reporting to each manager. The managers could then be contacted via a workflow tool, presented with their list of employees, and asked to validate whether it is still accurate.

The manager should be able to respond directly within the tool with any changes that may have occurred. The manager's changes could be populated directly back into the HR database or could be submitted for manual review by an HR representative. An enforcement process could be implemented to ensure that managers perform this task within a certain number of days of receiving the notice; reports could be generated to executive management to demonstrate compliance (or lack thereof).

Selecting a Solution—Suite versus Best of Breed

As of the writing of this book, Thor Technologies has recently been acquired by Oracle, eliminating the last of the major provisioning tools as a point solution. All of the top provisioning, single sign-on, and Web access control (WAC) tools are now part of vendor suites. However, most vendors price the components of their products somewhat individually, so there is still an option to pick and choose various components from different vendors.

The debate between suite solution versus best-of-breed point solution has been raging in the identity and access management space for a while now. Despite the consolidation in the marketplace narrowing the choices down to pretty much just suites, the argument is still valid because it all boils down to cost. The theory is that if you purchase a suite of products, all of the components of your identity and access management solution will already interoperate, saving you time and money on integration. But, if all of the components in the suite do not adequately meet your requirements, the money you save (and more) on integration could end up being spent on customizing the product to meet your needs.

The solution to this conundrum will vary by company, but your decision must be clear and well substantiated. As previously mentioned, any identity and access management solution will be deeply embedded into your infrastructure and touch (theoretically) every system and user in your enterprise. The solutions are extremely expensive, and the amount of time and effort it takes to get them working is substantial. This is not a decision you want to botch or something you want to rip out half way into the implementation.

The best way to ensure that you are making the right decision is to establish a core team of technically savvy people to do a good, old-fashioned, consulting-style requirements analysis. The team of people should include:

§  Your security architect, who should be familiar with identity and access management architectures, both generally, and as they apply to the specific vendors you wish to consider

§  A member of your IT architecture or infrastructure team who can add additional input into integration considerations

§  Someone from your user management team who can speak to the day-to-day pain points, issues, and needs as related to user provisioning and de-provisioning

§  A member of your directory services team because the directory is a key integration point with the provisioning tool

Once you have your core team and they have had a chance to interview key stakeholders to get their input, they should create a detailed listing of requirements based on stakeholder input as well as their expertise. You may choose to break down your requirements into a variety of areas for readability. Some suggestions of areas to consider include:

§  Functional. What must the tool be able to accomplish? For example, to what level of detail do you need the provisioning component to be able to provision or deprovision a user on a particular system? To which systems would you like to apply the WAC component? To what extent do you want single sign-on to work in your environment? What characteristics do you want the password self-service tool to possess?

§  Integration. What are the key systems in your environment that the tool must support out of the box? What other important systems do you know no tool will support out of the box for which you expect to build custom interfaces? What are the industry standard protocols that you use in your environment and that you expect the tool to use?

§  Architectural. Most vendors run their suite on a handful of platforms. For example, they may run on Windows or AIX operating system and on Oracle or Sybase database. What combinations of operating system, database, directory, and other components would be acceptable to run in your environment?

§  Compliance. What reports do you need the product to be able to produce? What are your reconciliation and introspection requirements? Do you expect the product to be "SOX certified"? If you are a government agency, do you expect the product to be able to handle mandatory access control (MAC) as well as discretionary access control (DAC)? Do you need the tool to have certification and accreditation (C&A) to a certain level (e.g., C2 or B1)?

§  Stability. Do you have requirements in terms of the vendor company's size, whether it is publicly traded or private, investments, and length in business? Would you be terribly concerned if it got acquired by another company?

§  Performance. What type of throughput does the product need to be able to sustain? What are your uptime requirements?

§  Security. Because we are discussing the evaluation of a security solution, you might think that security is adequately built into the product. But that is not always the case. Be sure to list your security requirements in terms of encryption, authentication to the product, recoverability, and whatever else concerns you.

When you list each protocol, each system, and each functional requirement in part, you will end up with a list that is hundreds of line items long. It is not unusual for a detailed requirements document to exceed 100 pages. As a brainstorming exercise, ending up with lots of line items means that you have carefully considered your environment and your needs. But you cannot expect to evaluate products reasonably based on so many detailed requirements. Therefore, the next step is to prioritize your requirements on a usable scale. The easiest scale to use is one to three. Any more than that and you introduce a level of granularity that makes the ranking process more arduous, without measurable value. The most common and useful way to set up your importance scale is as follows:

§  3 = Mandatory. This feature is absolutely necessary for your environment. If a product does not have this feature, it is a show stopper and the product should no longer be considered.

§  2 = Desirable. This feature would greatly enhance the usability of the system or would otherwise significantly add value. If this one feature is missing, it would not be the end of the world, but if multiple features ranked 2 were missing, that could aggregate into a show stopper.

§  1 = Luxury. It would be nice if this feature were available, but chances are most products do not offer it and not having it does not present any substantial problem. Of course, vendors that offer this feature should get some bonus points for it.

Your importance ranking should not be done with any specific product in mind. Rather, it should be done with your environment in mind. Focus solely on what is most important and relevant to you in the context of your company. In terms of ranking realistically, you should have a handful of items ranked 3 and a handful ranked 1. Most items will be ranked 2.

Once you have completed your requirements-gathering and -ranking exercise, you are ready to compare the vendors to it. First, select the vendors you wish to assess. For this initial exercise, you may want to consider all vendors who have a product that would be adequate for your company's size and needs. You may want to make some preliminary decisions based on the reports from research companies such as Forrester, Burton Group, IDC, Gartner, or others. Once you have selected your initial list of vendors, have one of your core team members schedule a call with one of the vendor's engineers and run through the list of questions. At this point, you should not divulge what the requirements mean to you in terms of importance. Simply have the individual answer your questions to the degree necessary for you to provide a scoring. A useful scoring mechanism for vendor capability is:

§  0 = This feature is not offered or the product cannot meet this requirement.

§  1 = This requirement can be met with some customization.

§  2 = This requirement can be met out of the box and only requires configuration to achieve.

§  If you are concerned about vendors scoring very similarly, you may choose to have a ranking of 3 = the product exceeds the specifications of this requirement. Basically, allow the vendor to earn "extra credit" if your expectations are exceeded.

Finally, for each vendor, generate the line-item scores and total score. The line-item score is simply the importance value times the capability value. For example, if you rank an item as having an importance of 3 (mandatory) and the vendor can meet that requirement (capability score 2), the line-item score would be 3 × 2 = 6. If you use the 0 to 2 capability scoring mechanism, 6 is the maximum score possible. If you allow the extra credit capability score of 3, 9 would be the maximum line-item score. Of course, 0 would be the minimum capability score possible. The vendor should not receive any credit for that which it cannot do.

After you have determined the line-item scores for each vendor, add them up to come up with a total vendor score. The vendor with the highest score is theoretically the most compatible with your environment. However, unless there is a very large and very clear discrepancy between the top two or three vendors, you may wish to do some further analysis here. Take a look and determine why one vendor scored better than another; is it because it was good across the board or because it got very high marks in just one area and mediocre marks everywhere else? Such a vendor may not be as beneficial for your long-term use as a vendor who did not score exceptionally well anywhere, but scored reasonably well across the board.

Irrespective of how variant the scores, it is imperative that you have your top choice and at least the runner-up come in and demonstrate their products in your environment. Take the top requirements that you documented and convert them into testing criteria and have the vendor demonstrate how those requirements are met. You may find that the vendor looks better on paper than in-house.

After you have done your paper-based assessment of prospective vendors and you have seen them perform live, you are ready to make the suite versus best-of-breed decision. If you have followed all of the steps outlined here, carefully documenting decisions that were made along the way and letting the requirements and not politics or personal preferences choose the product, chances are your selection will be the right one for your organization and you can implement with confidence knowing that you are doing the right thing and will not need to backtrack later. If, after a year or two, the requirements change drastically in a way that you could not have foreseen and someone questions your decision, you will have all of the evidence you need to demonstrate that, at the time, it was the best possible decision you could have made.

This section has been focused on the selection of an identity and access management solution. However, the methodology applies to any product selection and is a good way to ensure that you are making the right decision before issuing a purchase order.

Key Control Points | Identity and Access Management

Three critical controls are embodied in identity and access management: properly managing new hires, controlling access for users who transfer, and promptly terminating access for users who have left the company. These components are further described in the following subsections.

Starting Off on the Right Foot—New Hires and the "Least Privilege" Principle

It is very important to ensure that access is appropriately granted to new users in your organization so that they do not exceed the "least privilege" principle from day one. This principle specifies that a user should only have as much access as minimally needed to perform his or her assigned job functions—nothing more. Initially, as new users are learning the job or in training, it is conceivable that they require even less access than they will ultimately have. Certain unionized functions base privileges on tenure: users must complete a certain number of hours of work to obtain additional authority on the system.

The challenge for most companies with new hires is that there are not adequately defined roles and rules dictating what access the new person should be granted. Some companies also struggle with the concept of authorization and approval. Should a user's manager approve his or her access or should that fall to the data owner? 

Maintaining Control over Time—Managing Transfers and Segregation of Duties

Controlling access as individuals move through the organization is the most problematic area for most companies; this is where the most violations of segregation of duties occur. Segregation of duties is the concept that a person cannot perform two complementary job functions that could lead to the individual's ability to defraud the company. For example, someone who has functions in accounts payable should not also have functions in accounts receivable. Likewise, on the IT side, a system administrator charged with granting access to a system should not also be the one charged with approving that access.

Over time, a person who moves from position to position within the company could amass permissions that end up violating segregation of duties or the least-privilege principle. An important part of user management to ensure that old access is removed if no longer needed is the verification of access each time an individual transfers from one department to another, gets promoted, or otherwise makes a move within the company.

But how do you know when someone has transferred? Most companies struggle tremendously with this challenge. The problem is that most organizations do not manage job functions at the granularity level that could distinguish differences among all transferees. For example, if in your HR system a user's department is denoted as "Accounting," there is no way to determine from the HR record whether the user is part of the Accounts Payable team or the Accounts Receivable team. If the user transfers from the former to the latter, clearly an access change is needed, but a review of HR department changes will not identify this user as a transferee.

Even if you can identify that someone has transferred, there is the additional problem of identifying what access the individual previously had and what access is now needed. This is similar to the problem described earlier with new hires. Some policy-level decisions also need to be made on overlapping duties for a user who is in transition. Is it acceptable in your organization for someone to violate segregation of duties for a period of time while he or she transfers from the old position to the new one? If not, how will such transitions be handled? 

Terminations—Is That Person Really Gone?

Promptly removing access when a user leaves the company is considered critical to the auditors. If someone is no longer employed, he or she should no longer have access—period. But the process of accurately terminating a user can be daunting if you are unsure when a user leaves the company, if it is unclear what access he or she had in his or her job function, or if you did not have a strong transfer process to help you with access cleanups through the course of that person's career. Additionally, in some scenarios the person's termination date is different from his or her last day of employment. Nevertheless, an audit finding in the area of terminations is more serious than an audit finding in any other area of user management; whereas a small number of exceptions is acceptable in other areas, in the area of terminations it really is not. Therefore, you have two choices: mount a very serious effort to clean up terminations and tighten your processes or implement additional "mitigating" controls.

Identity and Access Management

Identity and access management encompasses a number of concepts, including password self-service, user access provisioning and deprovisioning, directory services, single sign-on, role-based and rule-based access control, and federated identity. Each of these components is briefly described below. This chapter will then focus on the components that are the most relevant to audit compliance and cost savings.

Password Self-Service

Password self-service is a technical functionality that allows users to reset their passwords by answering certain personal questions, rather than calling the help desk. The popular password self-service tools integrate into a number of commonly used systems and provide the user a self-registration function. The tool is configured to display a certain number of prewritten personal questions that a user must answer. Most tools offer the option to allow users to select a subset of the available questions—the ones that are most meaningful to them. Most tools also offer the option to allow users to create their own questions.

During the self-registration process, the user enters answers to the questions, which are stored securely for future use. When the user needs to reset his or her password, the tool randomly selects a specified number of the saved questions and requires the user to answer those questions. If the answers provided by the user match the answers provided by the user at the time of registration, the user is allowed to enter and confirm a new password. The tool then automatically sets that new password for the user on all systems with which it interfaces.

Most users can reset their password faster than they can reach a help desk representative; because password resets tend to be the single most frequent reason why users call the help desk, a significant cost savings can be achieved in reducing help desk staff if you can reduce the number of password-related calls. Password self-service offers the added benefit of synchronizing a user's password across multiple systems. This enables users to access more systems with just one password, reducing the likelihood that the user will write down his or her passwords or select an easily guessed password.

User Access Provisioning and Deprovisioning

User access provisioning and deprovisioning can be accomplished through a technical functionality whereby user IDs are created and permissions are granted automatically by a system, rather than by a person. The implementation and configuration of a user provisioning tool is highly complex, but if it is correctly done, it results in near-instantaneous provisioning (and deprovisioning) of user access. There are a number of advantages to implementing such a tool:

§  Users receive their access immediately, avoiding the need or inclination to share accounts with others while they wait.

§  Access is granted accurately every time, reducing the number of user complaints about incorrect implementation and eliminating audit findings around extraneous access that may have been inadvertently granted.

§  Access is granted uniformly to specified groups of people, simplifying audit reviews.

§  The tool can determine what access a user has, ensuring that terminations can be executed completely and accurately.

§  Most tools come with a built-in or associated workflow module that allows users to submit requests that can be automatically provisioned if they are asking for preapproved access. If the request is not preapproved, it can be automatically routed to an approver and, upon approval, the provisioning will happen automatically.

§  Automating a portion of user provisioning and deprovisioning can help reduce the user administration staff, resulting in a head-count savings.

There are also a number of challenges in implementing a provisioning tool, including:

§  Not all tools can provision or deprovision. Some tools can only create a user ID, and perhaps partially provision the ID. Much of the provisioning process—and therefore the deprovisioning process—may remain manual. It is helpful to determine, roughly, how many times a person's access is expected to change in your organization in the course of the average person's career. Then consider that an ID is only created once on each system. If the average number of expected changes is just five (and it will be more at most companies) and you consider that provisioning an ID is much more time consuming than creating the ID, a tool that can only create IDs is adding very little value.

§  None of the current tools on the market is compatible with every system. This is impossible. The top vendors do their best to interface "out of the box" with the major systems used in the marketplace, such as Windows, various versions of UNIX and Linux, certain mainframes, Oracle/PeopleSoft, SAP, the top Directory vendors, and so on. Most of the vendors provide software development toolkits (SDKs), application programming interfaces (APIs), or other similar functionality that allow you to build custom interfaces to systems that they do not support directly. If your company has a lot of home-grown or legacy applications, you may end up doing a lot of development work or employ the provisioning tool vendor's professional services to build all of the necessary interfaces at a high cost.

§  Many of the tools are still agent based to some degree. Provisioning tools these days can be agent based or agentless. "Agent based" means that an agent (a piece of code) resides on the target system. The tool interacts with that agent, which then executes commands on the target. "Agentless" means that the tool interacts directly with the target system through a compatible protocol, without the need of an installed agent. Many tools are still at least partially agent based and some are as yet entirely agent based. If yours is a large and dynamic company, you may find it difficult to implement an agent-based solution. Consider that you would need to deploy an agent to each one of your hundreds or thousands of devices, first testing that the agent does not interfere with the operation of those devices. Also, consider that each time you need to upgrade a device, you will need to ensure that the agent remains compatible. This must be weighed against a potential loss in functionality with a comparable agentless tool. In some cases, agentless tools cannot provision to the level of detail that an agent-based tool can, although that is not true of all tools. Finally, some provisioning vendors may charge you on a per-agent or per-seat basis, which adds administrative complexity and fluctuating costs due to the licensing true-up processes.

§  Provisioning tools rely on an accurate system of record. Whether this is your Human Resources (HR) system directly or a directory that pulls data from HR, if key user data is not available to the tool, it will not function.

§  Provisioning tools are only as good as the information they execute. Interfacing with target systems is only half the problem. Even if you can get the provisioning tool to communicate with all of your key systems, it still needs to know what to "say" to those systems. Some provisioning tool vendors have come up with clever tools and processes to help you more quickly determine what access everyone needs so that you can input that information into the tool and get it working. But at the end of the day, the tool will do what it is told and has no way of validating the accuracy of the access data you have input. If you code the wrong access instructions into the tool or the instructions are outdated or not sufficiently granular, the tool will diligently grant all of your users the wrong permissions.

§  Not all provisioning tools can do introspection or reconciliation. Introspection is the tool's ability to "look" at an existing target system and determine the users that currently exist on that system and the access that they have been assigned. Reconciliation is the tool's ability to compare what exists on the target system with what should be, according to its access programming, and do something about the differences. This should include creating reports, overriding the discrepancies on the target system, directly incorporating the discrepancies from the target system, or triggering approval workflows to validate the discrepancies before they are incorporated or overridden. Introspection and reconciliation are critical activities when a new system is brought under the management of a provisioning tool because these activities enable you to ensure that the system is "clean" from an access perspective; thus, it can be accurately managed going forward. If the tool cannot help you with these activities, although it may prevent additional violations from occurring, you may be stuck with manually trying to clean up potentially thousands of existing users to achieve a clean state.

In a perfect world, your provisioning tool will integrate with all of your platforms and applications, and it will accurately and granularly provision and deprovision users on a nearly instantaneous basis. You can then redeploy almost all of your user administrators, leaving just a few to manage access permission data on an ongoing basis to ensure that it remains accurate over time. Auditing of user access will be a snap: with the press of a few buttons, you will be able to generate reams of reports showing the auditors how everything is in perfect order—everyone has "least privilege" access, transferred users have all been accounted for and verified, and all terminated users have had their access revoked.

In the real world, your provisioning tool will:

§  Integrate with a hopefully not too small subset of your platforms and applications out of the box

§  Help you clean up existing user records through introspection and reconciliation

§  Provision and deprovision accounts to a reasonable level of granularity

Some manual intervention is not out of the question, reducing the number of user administrators that you can redeploy and eliminating the likelihood that your audit reports will be perfect. You will also be faced with months' or years' worth of development activities (or the vendor's professional services) to build additional interfaces, and some may never be worth building. Nevertheless, even partial automation can be a tremendous help in reducing your administrative costs, facilitating your audits, and making your user community happier.

Directory Services

Much of identity and access management involves creating and maintaining a repository of users and their various attributes, such as user positions, job function information, password self-service information, and so on. These attributes are most commonly stored in one or more directories. The directory structure must be architected so that there is a clear hierarchy of information that flows in the right direction. Because authentication and authorization in an identity and access management solution depend on the integrity and availability of the directories, it is imperative that the architecture account for this.

Single Sign-On

Single sign-on is a technical functionality that allows a user to move from system to system or application to application without having to re-enter authentication credentials every time. There are several ways to implement this functionality. Two common ways are by relying heavily on the directory and constantly referring to it for authentication information or by implementing an authentication system such as Kerberos. Single sign-on may have audit and security implications if it is implemented insecurely. A password or credential that is compromised will equate to a breach of all systems or applications the user is authorized to access. If adequate security controls are implemented in the single sign-on solution, there will be no audit impact or any hard cost benefit to the organization. But there will be an enormous perception of benefit from the users. Users will be thrilled not to type in their password all the time or remember multiple passwords, and they will view this as a significant time savings (i.e., soft benefit).

Role-Based and Rule-Based Access Controls

Role-based and rule-based access controls are procedural concepts at the core of identity and access management; without their definitions any provisioning tool you implement will be useless. Role-based access control is the concept that all users with the same job function will have the same system access, and users with different job functions will have different system access. Access roles tend to be fixed and apply consistently to everyone within a particular job function. Rule-based access control is the concept that users with certain attributes are allowed or denied certain system access. Access rules tend to be dynamic and are applied circumstantially—for example, based on location, time of day, other privileges assigned, seniority, completion of certain training, or other criteria.

Especially at large companies that have many individuals in specialized functions, it is impractical to formulate roles for the entire company 100 percent. The goal of role basing is to create some generalizations that allow for easier management of users. However, in executing this role basing, some large companies find that they have as many as — or more — roles than they have users. This clearly becomes counter-productive. Therefore, as with anything else, role basing should be done pragmatically. The 80/20 rule applies well here: define the most common 80 percent of what people need as access roles to facilitate user provisioning and audit validation. Handle the remaining 20 percent with access rules or an approval workflow.

Once established, access roles and rules will make the lives of your user administrators much easier and will enable you to implement an automated provisioning solution effectively. It will also make it easier to generate clean user reports for the use of your auditors. However, establishing the roles and rules is an enormously painstaking and largely manual process, and you can expect a multi-person team to take months to complete it.

Federated Identity

Federated identity is the set of technologies and processes that enables a user to log in with the same user ID and password on the systems of multiple companies or entities. Think of it as a sort of global single sign-on. At the core of the federated identity model is a directory that correlates a user's credentials from multiple sources. That directory serves as the translator for the user so that he or she can use a single set of credentials while the directory pushes the relevant equivalent to the target system. Clearly, this points to a need for interorganizational interoperability, and today that is still a very tall order. However, as more and more systems begin to use industry standard protocols, federated identity will become increasingly manageable to implement.

Common uses for federated identity include:

§  Employee benefits: Employees of your company can use their company network IDs and passwords to access their health insurance, retirement, and other benefits, despite the fact that the benefits information is maintained by the individual providers on their proprietary Web sites.

§  Government interagency communications: Most governments in this world have numerous disparate agencies that provide services to their citizens. It will be much easier for citizens to make use of the online services offered by these agencies if they can have one ID and password to give them access to all services. This in turn would increase the use of online government services, thus reducing operating costs for the corresponding agencies.

§  Electronic commerce: Many large retailers and manufacturers have hundreds or even thousands of suppliers and other business partners. Standardizing authentication between them would facilitate electronic commerce substantially.