Single Sign-On Through Novell SecureLogin 3.0
Articles and Tips: article
01 Apr 2002
Doesn't it seem that every resource users access today--from Windows applications to web services--requires them to create yet another username and password? To make matters worse, each application has different requirements for usernames and passwords. For example, one application requires a minimum length of ten characters, another requires case-sensitive passwords, while a third requires mixed alphanumeric passwords.
Consequently, when a user forgets a password or a seldom-used credential set, that user generally has little recourse. Either the user must call the IT help desk, or for applications and services that employ a user-managed identity model, the user may just create a new identity. As a result, each user may have multiple identities for a single web site or application. This situation isn't appealing to the user or to you as a network administrator.
Because security is one of the leading IT issues, managing usernames and passwords must be at the forefront of the issues that you address. To address these issues, Novell provides Novell SecureLogin 3.0, a Novell eDirectory-based authentication solution that gives users single sign-on access to virtually every application and service within your company's network. Users log in to the network one time, and SecureLogin then automatically authenticates them to any authorized applications and data they access during that session. With SecureLogin, users have only one username and password to remember, making it easier for them to access the resources they need while minimizing password-related help desk calls.
MANY SOLUTIONS TO A TOUGH PROBLEM
You can provide single sign-on access to users in several ways. For example, you can implement a single directory that all applications leverage natively. Because all applications use one directory, users have only one username and password. Unfortunately, this option is not technologically viable because many existing applications already use their own (or a particular vendor's) identity database.
You can also use a metadirectory to synchronize identity databases and thereby provide single sign-on. In a metadirectory, multiple data repositories are coordinated. Therefore, if a user changes a password on one system, the metadirectory synchronization technology replicates that change to all systems, synchronizing each user's credentials.
Although metadirectories, such as Novell's DirXML, are an excellent solution for synchronizing multiple directories in your organization, they are not necessarily the best choice for providing single sign-on.
Companies that implement metadirectories to provide single sign-on face three significant challenges:
Every application or system requires a connector to link it to the metadirectory. Although most metadirectories provide connectors for many common applications, connectors are not available for many applications.
Metadirectory deployments require significant expertise and time to implement.
Not all systems have the same password requirements. For example, some passwords are case-sensitive, and some passwords have length requirements and other such restrictions. Metadirectories cannot support changing passwords between directory systems in a way that meets the requirements of each system.
The Novell SecureLogin Approach
Novell SecureLogin presents a unique approach to the single sign-on dilemma. Instead of trying to homogenize all the logins using a single directory, SecureLogin recognizes when a login is occurring and then captures the credential information and securely stores it in eDirectory. SecureLogin can then provide this credential information in the proper format for future logins. In this way, a single system can support all the various permutations of login names and passwords.
The only caveat to this approach to single sign-on is that if someone breaks a user's password, that person has access to every system for which SecureLogin is handling sign-on tasks. One way that you can ensure the security of the network is to implement Novell Modular Authentication Services (NMAS), which enables you to require a secondary method of login such as biometric access or token access. (For more information about NMAS, visit www.novell.com/products/nmas.)
The SecureLogin Partnership
Few will argue that Novell eDirectory is one of the most reliable, scalable, and distributed directory services available. In addition, Novell has several unique security mechanisms: For example, Novell's SecretStore stores secrets on behalf of the user in eDirectory. If the user needs a secret, he or she can retrieve it from the eDirectory easily and securely.
Novell SecureLogin takes advantage of SecretStore and other eDirectory security mechanisms to deliver a single sign-on solution. (Novell SecureLogin is the result of a partnership between Novell and Protocom Development Systems [http://www.serversystems.com/]. Novell SecureLogin is distributed and supported through Novell Inc.)
Novell SecureLogin delivers single sign-on functionality to virtually every application and environment, including the following:
Windows 32-bit applications
Citrix and Telnet environments
E-mail clients, including Novell GroupWise, Lotus Notes, and Microsoft Outlook IBM and UNIX mainframe applications
More than 30 terminal emulators, including Attachmate Extra, Eicon Aviva, and IBM Personal Communications
Web sites accessed via Microsoft Internet Explorer and Netscape Navigator
Because Novell SecureLogin 3.0 is natively enabled to use SecretStore, any secret that the single sign-on software captures is automatically stored in eDirectory as part of a user's profile. A user logs in to eDirectory only once, and thereafter SecureLogin monitors any application that the user launches. If an application requires a username and password, SecureLogin automatically provides that information.
NOVELL SECURELOGIN COMPONENTS
Novell SecureLogin is composed of two major components--eDirectory and the SecureLogin software--which, in turn, include several software modules. Novell has created a simple installation that ensures you have loaded the right versions and components that SecureLogin requires.
Novell eDirectory and SecretStore
One of the primary components of Novell's single sign-on solution is Novell eDirectory, which includes the Novell SecretStore engine. Novell SecureLogin uses this mechanism to store and retrieve usernames and passwords. If you already have eDirectory 8.5 or above, you already have the SecretStore components required for SecureLogin.
Novell SecureLogin also requires that you install Novell International Cryptographic Infrastructure (NICI) client version 1.54 or above. SecretStore uses NICI to encrypt and decrypt secrets as they are sent to and from the workstation. NICI is included with SecureLogin. (You can also download NICI from Novell's web site.)
The SecureLogin Software
At the heart of Novell's single sign-on solution is the Novell SecureLogin software. This software inspects Windows and browser applications as they are running, checking for any type of authentication requests.
For Windows applications, Novell SecureLogin uses a published Application Programming Interface (API) that allows it to monitor any window a user opens. If the user opens a window that includes entry boxes for authentication, SecureLogin software captures the login information the user enters and stores it securely in the user's SecretStore.
The next time that familiar login box appears, Novell SecureLogin provides the login information automatically. SecureLogin retrieves the username and password information from eDirectory (via SecretStore) and provides this information to the application when the application requests it.
NOVELL SECURELOGIN FEATURES
Novell SecureLogin includes a number of features that make it extremely flexible, including the following:
Flexible policy support
Offline caching of credentials
Support for other directory systems
Enhanced Application Training
Although Novell SecureLogin supports many applications out of the box, many companies have custom applications and solutions that may not be familiar to SecureLogin. For this reason, SecureLogin includes an application-training component. Using this component, you can configure SecureLogin to automatically recognize nearly any application.
To provide this functionality, Novell SecureLogin uses a powerful scripting engine. When you "train" an application, SecureLogin creates a script that provides the user's credentials to that application. Because the script is text-based, you can modify it to include complex authentication routines and password policies (such as minimum lengths and mixed case).
For example, suppose you launch an application that Novell SecureLogin does not know and recognize. You simply launch the SecureLogin wizard to train the application. After the new application requests a username and password, you indicate to the SecureLogin wizard where the entry boxes are by dragging-and-dropping SecureLogin icons into the username and password boxes.
Novell SecureLogin can then determine which information the application needs to authenticate you. SecureLogin stores this information for use the next time you launch the application.
The entire process usually takes just a few minutes. After the process is completed, you--assuming you have ADMIN rights--can distribute login information about the new application to every SecureLogin client on the network. This way, you only need to train SecureLogin once about the application, and every SecureLogin client benefits. The process of distributing this information is explained in more detail in the next section.
Flexible Policy Support
One of the benefits of using eDirectory in a single sign-on solution is the way it can elegantly distribute policies based on hierarchy. For example, if you place a policy at the top of the directory hierarchy, that policy applies to all objects (including users) below.
By using this powerful feature of eDirectory, you can rapidly deploy a single sign-on infrastructure with little effort. For example, you can use policies to perform the following tasks:
You can leverage eDirectory to deploy trained applications (applications not previously recognized by SecureLogin) to individual users, groups of users, or the entire company. You simply assign the application to User objects, container objects, or the [Root] of the e-Directory tree.
You can set policies at a global-, departmental-, or user-level to govern which applications each user can access and which changes he or she can make to the SecureLogin client.
You can create and assign password policies to each application or globally. Password policies allow you to create a secure password environment by mandating requirements such as minimum password lengths, mixed case, and alphanumeric passwords.
Policy support is built in to the Novell SecureLogin client, ensuring that each client follows the policies you establish. To create and manage SecureLogin policies, you use Novell's NetWare Administrator (NWADMIN) utility or Novell's ConsoleOne management tool. (See Figure 1.)
Figure 1
Offline Credential Cache
One of the policies you can enable at the SecureLogin client is the ability to cache credentials. Caching credentials ensures that a user's single sign-on still functions when the user is not connected to the network.
If offline credential caching is enabled when a mobile user launches an application or visits a web site that requests a login, Novell SecureLogin provides the username and password just as it would if the user were logged in to the network. If the user changes a password, SecureLogin records that change in the cache and updates eDirectory the next time the user reconnects to the network.
Offline credential caching is encrypted and protected. Still you may not be comfortable with allowing a secondary cache of users' sensitive credentials. In that case, you can globally disable this function by setting a policy against it.
INSTALLING NOVELL SECURELOGIN
The process to install SecureLogin is simple. This article will cover a basic installation using eDirectory as the directory service. If you have already deployed eDirectory, then you have completed half of the installation. You must also ensure that NICI 1.54 or above is installed. If you have NetWare 6, the client CD includes NICI 2.02.
After you have installed NICI, launch the SecureLogin SETUP.EXE. The setup program will prompt you to choose which of the following components to install:
Management Modules. If you use the NWADMIN utility, ConsoleOne, or both, select the snap-in modules you want to install. The installation program prompts you to specify the location of the management tools and then to copy the snap-in files to the appropriate location.
NICI Support. If you don't know if NICI is installed or if you have an older version, you can select this option. The installation program will install NICI on your workstation. Remember, NICI is a prerequisite for SecureLogin to work with eDirectory.
The SecureLogin Client. You can de-select this option if you are installing only the management modules or updating NICI. Usually, you should select this option.
Because you must install Novell SecureLogin on each workstation that will support single sign-on, you can save time by using ZENworks for Desktops (www.novell.com/products/zenworks) to deploy all of the SecureLogin components.
A SAMPLE SECURELOGIN SESSION
The following two examples illustrate how Novell SecureLogin interacts with an application:
Capturing GroupWise Credentials
When you launch a Windows application that requires authentication, a dialog box appears--prompting you to enter a username and password. Because GroupWise is a SecureLogin-supported application, the SecureLogin client is immediately activated when you launch GroupWise.
After you enter your GroupWise username and password, a SecureLogin dialog box appears--asking if you want to save this information for future logins. (See Figure 2.) If you answer Yes, SecureLogin saves an application session and stores it in eDirectory. If you answer No, SecureLogin ignores this application from now on, assuming that you do not want to store those credentials.
Figure 2
If you said yes, the next time you launch the GroupWise client with SecureLogin installed on the workstation, you will see the GroupWise login box appear. However, SecureLogin will automatically fill in the credentials to authenticate you to GroupWise.
Capturing Credentials Through a Browser
Although a browser authenticates users differently than a Windows application authenticates users, the process for setting up single sign-on with Novell SecureLogin is similar. When you load a web page that requires login credentials, the SecureLogin client usually detects this request. If SecureLogin does not detect this request, you may have to train SecureLogin for that web site. (The SecureLogin documentation explains how to train SecureLogin in this way. In general, the process is fairly straightforward.)
If Novell SecureLogin detects the login request, it asks you for one other piece of information: Should SecureLogin use this credential for all web pages or just this one? (See Figure 3.) SecureLogin asks this question in case the web site does not maintain your authenticated state throughout the entire web site. Usually, choosing a single page is adequate.
Figure 3
The next time you launch your browser and load this web page, Novell SecureLogin detects the login and automatically provides the credentials necessary for login. In some cases (both with Windows and browser logins), SecureLogin may log you in so quickly that you may miss it!
CONCLUSION
The multitude of identities that today's users must manage have placed an unexpected burden on both users and IT managers. Faced with the prospect of memorizing numerous usernames and passwords, many users have resorted to creating simple passwords as well as recording the information where any unscrupulous party can discover it. Novell SecureLogin enables users to securely manage the myriad credentials they must know and use. Users log in once, safely and securely, and SecureLogin protects and provides credentials for any number of systems that users access.
JD Marymee writes for Technology Innovations Group Inc., a technical writing and consulting firm located in San Diego, California.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.