OS/400 and now i5/OS provide some interesting capabilities that enable single sign-on. But before you dive in, you must understand a few concepts and do some planning. This article begins a series intended to help you understand and use the single sign-on capabilities of OS/400 and i5/OS.

Single Sign-On

Over the years, various vendors have made several attempts to provide single sign-on capabilities. All of them, to date, have required a proprietary solution, were very expensive (from both financial and administrative perspectives), and were hard to keep current. That is, it was difficult to add new applications into the environment without significant changes to the application. Now, using Enterprise Identity Mapping (EIM)--technology that originated from IBM Rochester--and an authentication mechanism called Kerberos, single sign-on is achievable and affordable by the average iSeries shop.

The reason single sign-on is such a big deal is because password administration costs organizations a lot of money. When passwords are forgotten or otherwise need to be reset, companies must bear the expense of having to staff personnel or purchase software to reset the passwords--not to mention the end users' lost productivity. To end users, passwords are a big deal because (as I'm sure we can all agree) it's a real pain to remember all of those passwords! At a minimum, users typically have to remember two passwords: their network password and their OS/400 password. But the numbers start to add up as you consider OS/400 sign-ons, application passwords, Web account passwords, Instant Messaging passwords, email account passwords, etc. Of course, we all try to make as many passwords as possible be the same, but something always prohibits us from that, so we are back to remembering multiple passwords.

In the past, solutions have concentrated on synchronizing passwords around the network, sometimes caching the password to be used wherever required. Obviously, problems arose when passwords became out of sync, so these solutions have not met with widespread success.
Since synchronizing passwords has not been successful, what are your options? When considering single sign-on, you must step back and think about the problem that you're really trying to solve. So let's look at what passwords are used for. Passwords are used to authenticate a user. ("Authenticate" means to make sure the users really are who they claim to be.) So if you could use something else to authenticate the user, perhaps that is a more viable solution. Enter Kerberos.

Kerberos

Kerberos (besides being the three-headed dog that guarded the gates of Hades in Greek mythology) is a well-known and widely accepted network authentication protocol developed by Massachusetts Institute of Technology (MIT). Kerberos allows you to provide a password once and then use a "ticket" as proof of authentication to other places in the network that would normally require a user ID and password. Using Kerberos, EIM, and Network Authentication Services (NAS)--which is the OS/400 and i5/OS implementation of Kerberos--a single sign-on solution can be achieved. (Note: IBM had to call its implementation of Kerberos "Network Authentication Services (NAS)" because MIT holds the trademark on the Kerberos name. While you will see the term Kerberos in the description of the function, it cannot be used as a product name.) Before we jump right into single sign-on planning and implementation, however, we need to discuss Kerberos and how it fits into the single sign-on scenario.

Authentication Using Kerberos

Stored in the Kerberos Key Distribution Center (KDC) are "principle" names (Kerberos term for a user ID) and passwords. When authenticating using Kerberos, a user supplies a principle and a password, which are then compared to what is stored in the KDC (Step 1 in Figure 1). If the principle and password match, the KDC sends a "ticket granting ticket" (TGT) back to the client (Step 2). When a user tries to access a service on the network that requires authentication, the client sends the TGT back to the KDC and requests a service ticket (ST). The client then sends this service ticket to the service being requested (Step 3). Assuming that the service accepts Kerberos STs, the session is established.

Figure 1: The Kerberos Flow (Click images to enlarge.)

Still Missing a Piece

We've discussed how Kerberos is used for authentication, but is authentication all that is required to enable single sign-on? No. Once you sign on to a system, what happens? You take on the identity of the profile under which you were authenticated. You are able to perform the tasks and run the applications and download the files to which the profile is authorized. You see, it is not sufficient to simply get logged on to the system. Once you're on the system, you must take on some identity so that you have the necessary authorization to perform your job duties. Kerberos enables authentication, but how does the system or the application or whatever you are signing on to know who you are and what identity you should take on? Enter EIM.

EIM

First, let me explain that EIM is not a solution unto itself. Rather, it is enabling technology. In the case of single sign-on, it solves the problem of who you're supposed to be after signing on to a particular system or application. You see, this wouldn't really be a problem if users were defined in one place. But that's not the case in the real world. An enterprise can easily have users defined in Windows Active Directory, OS/400, J.D. Edwards, Infinium, Domino, etc. Therefore, for single sign-on to be as successful and non-disruptive as possible, there has to be a method of determining what user identity to assume once logged on. Figure 2 shows the parts that Kerberos and EIM play.

Figure 2: Kerberos and EIM Roles

In its most simplistic form, EIM keeps track of all the ways that a person can be identified throughout the enterprise. At one of my clients, I am known to the network as #CWOODBU, to Lotus Domino as CWOODBUR, and to most of the iSeries systems as SECOFRCW. EIM has one entry for me--Carol J Woodbury--and associated with that entry are associations about how I am to be known on a given system or to a given application. Figure 3 shows the EIM associations. Carol J Woodbury is the EIM identifier, #CWOODBU is how I am known on the Windows 2003 server, SECOFRCW is how I am known on the production system, and UCJW is how I am known in the test system.

Figure 3: EIM Associations

Let's walk through the single sign-on scenario using a real example. Suppose you sign in to a Windows network in the morning. Windows Active Directory uses Kerberos as its authentication mechanism. So if you are already logging in to a Windows 2000 or Windows 2003 server to gain access to your network and you are running Windows 2000 or XP on your desktop, then you are already using Kerberos authentication. Once you log into your network, the server sends a TGT back to your desktop. You are running iSeries Access for Windows V5R2 or V5R3, and you want to sign on to the system, which is running OS/400 V5R2 or i5/OS V5R3. You click on your 5250 emulation desktop icon, which would normally present you with a sign-on screen. However, your system administrator has configured NAS and EIM on your system. When you click on the icon this time, the 5250 client on your desktop grabs the TGT, goes back to the Kerberos server, and asks for an ST. The client then sends the ST up to the Telnet server on OS/400. The Telnet server has been enhanced to accept an ST in lieu of a user ID and password for authentication. After doing a lookup in the EIM registry to know what OS/400 user profile is represented by the principle named in the Kerberos ST, the sign-on screen is bypassed, you are launched directly into your initial program, and you are now running with the authorities of UCJW. See Figure 4.

Figure 4: Kerberos and OS/400

This has been a whirlwind tour of how Kerberos and EIM enable single sign-on on OS/400 and i5/OS. Next month, I'll discuss the planning that you will want to do and the considerations you will want to make before implementing single sign-on.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services and security assessments, including the risk assessment product, SkyView Risk Assessor for OS/400. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security, now available at http://www.pentontech.com/education.

Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..