Single Sign-On: Then and Now

October 22, 2012 Dan Burger

When single sign-on was integrated into the IBM OS/400 operating system in 2002, it was one of the highlighted technologies in the V5R2 release. In the right hands, it allowed system administrators in IBM midrange shops to set up user authentication beyond the boundaries of the i5 system to include multiple servers and applications–Microsoft Windows, Unix, Linux, and others–but primarily the target was Windows, where PC5250 emulators were the bull’s eye. There was widespread use of green-screen applications with emulators running those applications from a menu.

Ten years later, why is single sign-on so rarely used? The benefit of lowering costly help desk requests for password resets has proved to deliver a quick return on the implementation investment. What stands in the way of this technology?

Pat Botz has a few answers to that question. Botz has worked with a lot of IBM i shops, from his days as the lead architect for OS/400 security, during his tenure as team lead for IBM’s Lab Services Security Consulting group, and up to the present as the owner of Botz & Associates, his consulting services company.

“When IBM was designing the use of single sign-on (SSO) specifically for IBM i customers, the idea was that companies would implement it on their own. That hasn’t happened to the degree it was anticipated,” Botz says. “Administrators don’t have time to learn what they have to learn to implement many technologies, including single sign-on. It could take a painfully long time to implement because of a lack of comfort related to not having the time to learn about single sign-on.”

Complexity does have a way of derailing all kinds of projects before they ever leave the station. As Botz points out, most organizations that use IBM i use it because they want to manage their applications and their businesses. They don’t want to manage technology.

Business strategy is supposed to be realized by the technology a company deploys. The technology is not supposed to devour the business. There has to be that often-discussed business and technology alignment that is the identified goal, but it remains less often reached than imagined. Nowhere is this more apparent than in instances involving the integration of disparate systems. SSO is about getting disparate systems to talk to and trust each other.

“It requires integration at the technology level, not the application level and not even at the OS interface level,” Botz says. “Because of that, administrators find the need to understand the iSeries and the other domains–Windows, Unix, Linux, and even Mac. That is a daunting task for administrators.”

The perception of cost has also been a barrier. Third-party software is expensive and there’s plenty of it available. And the fact that there is third-party software available says something about the complexity of technology that exists within the system without the need for add-on products. The authentication layer is in the systems in your network–IBM i, Windows, Unix, and so forth–and using the technology that is part of system investment is usually a better return on investment, right?

“For the average IBM i administrators, they understand their side, the IBM i side,” Botz says, “but not the other domains: Windows, Unix, Linux, and even the WebSphere, Tomcat and Apache sides. And then you can add the third-party application sides of it. Going into this without a background in authentication technologies, an administrator might say, ‘There’s no way in hell that can be anything but expensive.'”

SSO environments provide access control to multiple, independent but related software systems using a single password. Users log in once to their desktops and gain access to as many of the multiple systems on their network as they take the time to configure. Sign-on credentials are often different for each of the systems, but SSO has a mechanism for translating desktop user names into corresponding user IDs on other systems. Therefore, users can sign on to each SSO-configured system in the network, regardless of whether the user names and passwords are the same.

Also detrimental to the adoption of single sign-on is the name itself.

“The term single sign-on leads many administrators to think of SSO as a 100 percent solution,” Botz says, “and then as soon as they find one element where SSO doesn’t work as a 100 percent solution they disregard the technology as being incomplete because the very definition of SSO is not being met. The goal is not single sign-on. The goal is to reduce a very expensive process of managing user IDs, passwords, and authentication across the disparate environments.”

Botz told IBM’s marketing people that single sign-on was a confusing name. (Whether IBM actually prefers confusing names is a can of worms that often sidetracks technology and business discussions. Visit any of the forums or social media sites if you just want to rail on marketing or product naming aggravations.) In the case of SSO, Botz describes the disorientation: Does SSO mean one password is stored in one place and used for everything? Does it mean the password is stored in multiple places? Do you explain single sign-on in terms of passwords? Does that mean everywhere you login in you have to type in the same user ID and password? Is it that you don’t have the same ID and password everywhere, but you don’t have to sign in anywhere at any time?

The point is people have different models in their heads.

“SSO is techno-geek, computer-speak,” Botz says. “We have to get by that and look at it as a business decision. You have to recognize it as a means of reducing a current cost of doing business–costs that are attributable to a help desk and the costs incurred because workers are unable to sign in because of forgotten passwords. SSO can significantly lower that cost.”

Joe Hertvik, technical editor for IT Jungle‘s Four Hundred Guru newsletter wrote a series of articles on the single sign-on topic during 2005, beginning with Getting Ready For Single sign-on on April 27, 2005. Additional articles were published in Four Hundred Guru on May 4, May 18 and May 25. These are good references for those who want a deeper dive into the technical details of configuring systems.

An IBM Redbook titled Windows-Based Single SignOn and the EIM Framework on the IBM eServer iSeries Server and an article titled Build and implement a single sign-on solution, which deals with building SSO into applications are other sources of reference material. And Pat Botz can be reached via the Botz & Associates website.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search