A Guide to Practical Single Sign On

The average systems administrator assumes the purpose of SSO is to allow end users to access any IT computing resource after logging into the network a single time—a true single sign on.

But this narrow view of SSO leads to the erroneous assumption that any SSO solution that requires end users to authenticate more than once is not a suitable solution. This purely technical view of SSO will lead to over-priced, overly complex solutions that actually undermine the true value of SSO.

The real purpose of SSO is to significantly reduce the high cost of managing passwords across the organization. Reentering a user ID and password is annoying. But from an organizational cost point of view, it doesn’t take much time or money—assuming the user knows and enters the right user ID and password the first time. No, the real cost is all wrapped up in remembering/finding, changing, resetting, and getting help with their passwords . . . all the frustrating parts.

The Cost of Managing Passwords

Why is it so costly to manage passwords? To answer this question, we need to provide a little background on user IDs and passwords. The IT organization is responsible for providing secure access to the company’s computing resources. This is done, almost universally, by providing each employee a user ID and associated password for each system (and sometimes also for applications) they need to access.

Because each person has multiple user IDs and passwords, managing them has a multiplier effect. Rather than spending time to manage X number of users, we actually have to manage X number of users times Y number of user IDs per person. You might think the cost of managing each user ID is the same whether the person it represents has one user ID or 50. That is, the costs scale linearly. However, the cost to manage passwords tends to scale more exponentially than linearly. In other words, the cost to manage 50 passwords is more than 50 times the cost to manage a single password. This is because complexity increases non-linearly with the increase in 1) the amount of information to remember and 2) the number of different types of transactions required to change all of them. What seemed trivial in the days of mainframes and terminals explodes into a large and significant cost for the entire organization in a distributed computing environment.

What costs are associated with user IDs and passwords? It’s the costs of the create, manage, and delete operations on each of them. Management operations include the cost to change the user ID and/or password and the costs associated with debugging failed logins, resetting passwords, etc.

Of these, the cost to manage passwords is, by far, the single most costly aspect of using user IDs and passwords. Why? Because you spend much more time managing passwords than any other attribute of a user ID. Once a user ID is created, the only attribute that changes, typically, is the password. If any other attribute changes, it typically is changed once at most. On the other hand, the password attribute is changed multiple times. And even in organizations that don’t require periodic password changes (yes, there are still some of those around), there are still cases where sign-on failures occur and passwords need to be reset.

The real purpose of SSO is to significantly reduce the high cost of managing passwords across the organization

The Multiplier Effect

In the average organization, three different constituencies are affected by the cost to manage user IDs and passwords: end users, administrators, and help desk personnel. End users, obviously, need to remember (or get help remembering) and manage passwords.

Administrators and help desk personnel are responsible for creating, changing, and helping people manage their user IDs and passwords, as well as for helping people log in when they lock themselves out. Managing passwords isn’t limited to helping users set or reset passwords. It also involves helping users debug sign-on failures and then fixing the problem. Of course, most problems associated with being unable to access computing resources are due to password-related problems. In effect, everyone in your organization is affected by the cost of managing passwords.

Get an instant demo of Single Sign On >

Across all organizations, most of the cost of managing employee access to computing resources is tied up in the cost of managing passwords. Most people are shocked by the magnitude of these costs. When you add up the time spent managing passwords by all end users, administrators, and help desk personnel in an organization, plus the time waiting on the phone for a solution, and the time it takes every employee to change all their passwords four or more times a year, these costs are surprisingly high.

When you understand the real cost of managing passwords, evaluating SSO solutions becomes so much easier. The only valid business reason for embarking on an SSO project is to significantly reduce the cost of managing passwords. Conversely, this means SSO solutions should not be judged by how many sign-on prompts they eliminate.

This insight has several implications:

1. Before looking for solutions, you need to accurately estimate what you currently spend on managing passwords.
2. For each solution you consider, you need to accurately estimate how much it will cost to implement and manage your solution over time.
3. For each solution you consider, you need to determine how well that solution's approach to SSO actually reduces the cost password management in your organization.
4. When considering potential solutions, you need to compare the projected return on investment (ROI) between them in order to select the best one for your organization.

When you understand the real cost of managing passwords, evaluating SSO solutions becomes so much easier. 

More Problems Caused by Multiple Passwords

While reducing the obvious costs of managing multiple passwords is the primary goal, SSO also helps reduce costs that are more implicit. Specifically, the costs associated with the increased risk accepted by organizations due to mechanisms employed by users to help them remember and manage passwords. These mechanisms often impart very high risk onto the organization.

Some examples of these mechanisms are:

• Easily guessed passwords
• Written lists of passwords located under keyboards, desk drawers, overhead bookshelves, on top of the desk, or written on whiteboards
• Lists of passwords stored in files on workstations or network drives
• Shared user IDs/passwords

A physical audit is almost certain to find most of these. True, there are ways to “better” use some of these mechanisms (e.g. encrypted stored files), but they only serve to reduce the amount of additional risk the organization accepts.

In addition to severely impacting productivity, managing multiple passwords tends to reduce employee satisfaction and morale, which can lead to other behaviors that may be detrimental for the organization

The costs associated with these problems require risk management and analysis techniques and thus are much more complex to measure. However, the easily measurable costs are large enough that that there is usually no need to account for these additional costs.

In short, SSO projects should be driven by business considerations, not technology

As stated earlier, SSO is a solution to the business requirement to reduce the cost of providing secure access to computing resources. As such, return on investment is the best metric to use to select the best solution for your organization. Before describing how to calculate ROI for SSO projects, we’ll discuss the process of identifying the potential solution, or combination of solutions.

The Process

The first step is to determine how much your organization currently spends on user ID and password management. We describe this process briefly in the "How to Calculate ROI for SSO Projects" section below.

The next step is to understand your network environment. This involves answering the following questions:

• How many user IDs, on average, does each end user manage today?
• How many different types of systems, legacy applications, client/server applications, and web-based applications does the average user access?
• How many external web applications does each user access?
• Since you typically don't manage user IDs and passwords for these applications, do you want to include these in your solution?
• What specific types of systems does each user access? What specific applications does the average user access?
• Do your users initially authenticate to a Windows domain before accessing other services?
• Do any of your users access your internal network over the internet?
• If so, how do you facilitate this capability? For example, do they use a VPN? If so, what specific VPN solution do you use? Does the VPN solution require a separate user ID and password? Does it use the person's Windows domain user ID and password?

Your specific answers to these questions will begin pointing you toward the best combination of approaches to use in your environment.

The next step is to determine which, if any, SSO approach seems to address the password management issue for the greatest number of people and/or the most types of user IDs. Then identify which approach affects the next greatest number of people or user IDs

Next, use the results from the previous steps to begin identifying specific potential solutions. 

Now, you need to investigate each potential solution to understand how, at a high level, they provide the capabilities they claim. This step will weed out some of the options.

For each remaining option, calculate the estimated ROI for that solution. This calculation is not only necessary, but also not that difficult.

Many companies will find that a single solution reduces password management costs by 80 percent or more. Assuming the cost to acquire, implement, and manage that solution is relatively low, many companies will choose not to address the remaining 20 percent of the cost. In other words, if the ROI for a single solution is large enough and the ROI to address the remaining costs is too low, it might not make sense to attempt to address the remainder of the costs.

How to Calculate ROI for SSO Solutions

Calculating the ROI for SSO projects requires an estimate of the current cost of managing user IDs and passwords, the total cost of the password solution(s) you are considering implementing, and an estimate of how the solution will reduce the overall cost of managing passwords.

You can estimate the current cost of managing passwords by adding up the time, on average, that end users spend changing passwords and getting help from the help desk and or administrators and applying an average burden rate (or salary) for the entire company to that time.

Added to this is the cost of the time that administrators and/ or help desk personnel spend on password related issues. The burden rate applied to administrator/help desk time is often higher than the average burden rate across the whole organization. When calculating the cost of a solution, you need to include the cost to acquire, the cost to implement, and the cost to manage as well as any yearly maintenance charges.

“Managed” SSO services often provide the greatest ROI for SSO projects; assuming the service provider doesn’t sell or receive any kind of monetary remuneration for selected solutions. Vendors providing these services already have the technical and business expertise required to help you identify, implement, and support SSO solutions. When provided at a reasonable cost, managed SSO services will provide the best solution at a fraction of what it would cost the average organization to develop in-house expertise. In addition, the ongoing support of your solution gives you piece of mind that if any problems do crop up, you have the expertise needed to resolve it readily available.

Of course, just as with any SSO solution, you need to do an ROI calculation for any managed SSO service you consider. Then you need to compare the ROI for managed services against any other solutions you may identify. Only if the ROI for managed services is better should you choose this solution.

An Example: Managed SSO

Following is just one example of how a managed service by an experienced SSO consultant can expedite the path to cost savings and positive ROI:

Step 1: Evaluation and Project Plan

A typical SSO engagement with Fortra starts with a complimentary evaluation call—usually 30 to 45 minutes— to discuss the customer’s environment and requirements. Usually, the environment includes a Windows domain and one or more non-Windows systems, such as UNIX (AIX), Linux, or IBM i. Some environments are far more complex, others are more straight-forward.

Based on your input during the evaluation call, we can create a proposed statement of work outlining all aspects of the project, including price. If your environment includes applications that require specialized attention, that will be called out.

Contrast the speed of this process to the elapsed time necessary to create a project plan using internal resources, even with a project leader who already has some SSO experience.

Step 2: Internal Preparation

The most important thing you can do to prepare for SSO implementation is to ensure that your host name resolution for your server systems is consistent between the Windows domain and the server system itself.

Typically, the best way to do this is to configure your server to use the Windows domain DNS server as the primary host name resolution service. You should maintain a host table file on your server only if there are server applications that use non-standard host names to access one or more remote systems.

You can also generate a CSV file containing Windows user IDs, first and last names, middle names and/or initials (if any), and if your company uses them, the employee numbers. This information can be quickly and easily dumped from Active Directory.

Step 3: Implementation

For the remainder of this example, we’ll assume the environment includes one or more IBM i systems; although the example would be much the same if the servers were UNIX, AIX, Linux, Mac, or any other OS.

SSO setup is typically done via a single interactive, online session with your Windows (or Active Directory) administrator and the systems administrator of the nonWindows server(s). We give the administrators presenter status, so we can see their desktops while they do the typing under our direction. This protects your systems and helps cement the knowledge transfer

Together, we work through the following set-up process, making configuration choices appropriate to your unique environment and troubleshooting anomalies as they occur.

1. Network Setup
2. Kerberos Configuration
3. EIM Configuration
4. Add Servers to SSO Network
5. Test
6. User Identity Mapping
7. Enable SSO for All or a Subset of Users

This entire implementation stage typically takes less than a day.

For many customers, Kerberos and EIM enablement is all they want and need. In this case, their end users no longer need to have a password even on the non-Windows server(s) configured for SSO. This eliminates all the cost associated with managing passwords on those servers.

Step 4: Ongoing Support

Although SSO technology tends to be “set-it-and-forgetit,” the environment it manages is not. Periodically, OS and application changes conflict with Kerberos and EIM settings. When this happens, it’s critical to have quick access to a resource experienced in troubleshooting SSO. This ongoing support is an important part of a managed SSO service.

In addition, as you add new applications, you and your users will want them included in the SSO network. And some customers want to extend SSO to web applications, Lotus Notes, SAP, or other critical applications. In most cases, the cost of managing passwords in these other environments can be significantly reduced, but this requires additional configuration and sometimes additional software utilities. The consulting time required to analyze the application(s) and determine what can be done is covered in the basic managed SSO support contract. If the customer decides to proceed with our recommendations, the additional work is covered under a separate contract.

Finally, ongoing support comes in handy during audits and when you add or change servers, host names, or IP addresses.

Eliminate Administrative Overhead with Fortra's EIM Bot

When users log onto the IBM i using SSO, their Windows credential is passed on to Enterprise Identity Mapping (EIM) that performs a lookup to find the correlating IBM i user profile. Under most SSO services, maintaining the EIM domain can be a hassle. Users are constantly being added and removed, resulting in a great deal of administrative overhead which comprises a large portion of the cost of support.

Fortra’s EIM Bot eliminates this overhead by automating the administrative actions associated with adding and removing users in EIM. The EIM Bot takes demographic information from the active directory and uses that to create or remove entries for the users.

Ensure EIM Continuity with High Availability

Fortra’s SSO service provides customers with two copies of the EIM domain maintained by the EIM Bot. This enables the bot to update both copies with any changes made to the active directory so that, in the event of maintenance or any unplanned downtime, customers can switch over to the second EIM domain without experiencing an extended service interruption.