Single Sign-On Myths

by Pat Botz

I have talked with many IBM iSeries users and independent software vendors about the eServer single sign-on strategy and the iSeries OS/400 implementation of that strategy. It has become apparent that there are several misconceptions. In many instances it is easier to understand something by learning what it is not, so that's the road this article is going down.

Most of the myths and misconceptions are related to a new technology called Enterprise Identity Mapping, or EIM. EIM is one of the technologies exploited by the single sign-on strategy. IBM rolled out this technology at the same time it announced the single sign-on implementation. I believe this is partly what has led to some of the misunderstandings rumbling around out there.

Here is my list of the most common myths and misconceptions about single sign-on.

Myth 1: EIM itself is the single sign-on strategy.

I probably run into this one most often. EIM is one of the technologies used in the single sign-on strategy, but it alone does not provide single sign-on. The other primary technology in the eServer single sign-on strategy is Kerberos authentication.

EIM is an identity mapping mechanism, nothing more and nothing less. It takes two pieces of information as input and returns a third. More specifically, EIM accepts as input a fully specified "source" (that is, a known) user ID and a "target" user registry definition name, and returns a user ID (or multiple IDs), defined in the target user registry, that is associated with the specified source ID.

A fully specified user ID requires the user ID name or number, plus the type and "instance" of the user registry in which that user ID is defined. The instance of a user registry refers to a specific implementation of a type of user registry. For example, OS/400 is a type of user registry. An OS/400 defined on TCP/IP address 9.9.9.9 is a specific instance of that type of user registry.

EIM encapsulates the information about a user registry in a user registry definition. Registry definitions merely refer to a real user registry that exists somewhere in the network. Administrators provide an arbitrary name for the registry definition, along with the type and instance of the real user registry. The names of EIM user registry definitions are used throughout the rest of EIM to refer to specific real user registries.

An identity mapping lookup operation accepts a user ID and the registry definition name representing the specific user registry in which that user ID is defined (a fully qualified user ID) and the user registry definition name of the target registry in which the caller wants to find an ID associated with source ID. For example, botz, OS400TestSystem is a fully qualified user ID: botz is defined in the user registry represented by the registry definition named OS400TestSystem, and the caller wants EIM to return a user ID defined in another user registry represented by OS400ProdSystem, which is associated with the source ID.

As you can see, EIM returns answers to questions about identity associations. While this is very useful as an infrastructure for building solutions to problems such as single sign-on, it is not a single sign-on solution by itself.

Myth 2: EIM is an authentication mechanism.

IBM designed EIM to be an identity mapping infrastructure that is usable by any operating system or application. It is not an authentication mechanism.

The eServer single sign-on strategy relies, primarily, on two technologies: Kerberos and EIM. Kerberos is a distributed authentication mechanism. IBM chose it, for a number of reasons, as the initial "foreign" authentication mechanism that operating system interfaces would optionally support in addition to the native OS/400 user profile and password authentication mechanism. A foreign authentication mechanism is any authentication mechanism not provided by the operating system or application performing authentication.

EIM, on the other hand, allows an entity (an operating system or an application) to use a foreign authentication mechanism while continuing to rely on the native authorization mechanism.

Myth 3: "We don't use Kerberos for authentication; we use Active Directory."

If I had a nickel for every time I heard this one, I'd be able to retire tomorrow. When a company chooses to define a Windows 2000 or XP domain, information about users defined in that domain is stored in Active Directory. However, the authentication mechanism used by Windows, when those users log in to a Window's domain, is Kerberos. This is one of the reasons why IBM eServer chose Kerberos as the authentication mechanism for single sign-on.

Myth 4: EIM synchronizes passwords.

EIM only keeps track of the relationship between user IDs defined, stored, and managed in real user registries, somewhere in the network, and the real person or entity that those user IDs represent. Not only does EIM not synchronize passwords, it doesn't keep track of any attributes associated with a user ID in the real user registry.

Myth 5: The single sign-on strategy only works with Windows.

Kerberos is widely supported on most industry platforms, either natively or as an add-on application. This misconception probably arises because many IBM-provided applications enabled for single sign-on happen to be available on Windows. This does not mean, however, that independent software vendors and customers can't write or use Kerberos-enabled applications on other platforms. Additional operating system and application interfaces may likely be enabled for single sign-on in the future.

Myth 6: EIM means user management.

EIM is Enterprise Identity Mapping. The "m" stands for mapping, not management. EIM itself does not create, delete, or change users in any user registry. What may cause the confusion here is that a user management function could be more easily built on top of the EIM infrastructure. When you analyze the problem of enterprise user management, it becomes clear that the hardest part is tracking the relationship among user identities and the people or entities those user IDs represent. EIM provides a "black box" solution to the identity-association problem. This allows application programmers to concentrate on the more interesting part of the problem: the actual management of the user IDs.

The Truth Is Out There

All of these myths and misconceptions have been told to me repeatedly. And those who told them to me heard them from some other misinformed person. If you hear any of these, you can now set the record straight. To understand the single sign-on strategy and how it works, and to get hands-on experience in configuring it, plan to attend the focused education roadmap for single sign-on at the fall COMMON conference and expo. This focused education roadmap includes the following sessions: (22FA) single sign-on enablement; (23FA) Kerberos: the underpinnings of single sign-on; (26FA) configuring single sign-on; (31LD) lab: implementing single sign-on; and (44FA) single sign-on: the hard part.

The fall COMMON conference and expo is scheduled for September 7 through 11, in Orlando, Florida. Registration information is available at www.common.org.

Pat Botz is the lead architect for OS/400 security and a member of the eServer security team. Pat led the design and development of eServer single sign-on and Enterprise Identity Mapping. E-mail: botz@us.ibm.com

Sponsored By BYTWARE

I thought our system was secure. Then I installed StandGuardAudit and StandGuard Anti-Virus. I found 53 users with delete authority, 3,000+ viruses on the IFS, and security policies being bypassed. I knew I had to correct things fast! I read the FREE white paper "Top Security Issues for the IFS" and got the StandGuard Security Suite. Now all is well. www.bytware.com/security_special.html