Authentication

Authentication is one of the most powerful features offered by the KeyServer Package, but it is also one of its most complex. While it can greatly enhance control of programs, authentication can also make the configuration process more involved. Before using the authentication features of KeyServer, carefully read this chapter and the first Appendix.

Authenticated and Guest Access

Depending on your environment and the licenses you are managing, you may wish to restrict access to the KeyServer, and to individual licenses on the KeyServer. For example, a KeyServer might be configured to restrict access to users who type their individual name and password, or it might provide service to anyone who types in a single KeyServer password known by all the valid users. With individual names and passwords, it is possible to give different access to distinct users. This is analogous to a file server, where access to certain objects on the file server is restricted to users who enter a valid name/password combination.

The process a user follows to gain access to your KeyServer is called authentication. Once the user has passed the required test (e.g., typed the proper password), the user is authenticated. A user is not authenticated if they fail to satisfy some requirement of the active authentication method (e.g., fail to type an acceptable password). By default, KeyServer will deny access to users who are not authenticated, but you can grant partial access to unauthenticated users by allowing "guest" logons.

Access to KeyServer and individual programs can also be based on the Apple Talk zone, IP address, or IPX network. You use the Network Access dialog in KeyConfigure to set up location-based access restrictions.

The simplest authentication method, All Authent, is the default. With this authentication method, every user with KeyAccess installed has equal access to the KeyServer and all of its licenses, so enabling Guest access has no effect. Other authentication methods that distinguish one user from another can be used to set up groups of users, and then different license pools can be assigned to groups within each Control. A license pool that has no associated group, a common license pool, will be available to all users. When Guest access is enabled, the guests (i.e., non-authenticated users) will have access only to the licenses that are in common pools.

As an example, consider the case of the Single Password authentication method. With no Guests allowed, KeyServer will give full access to all Controls for all programs to anyone that enters the correct password. Anyone who doesn't know the single password will get no service at all. If Guest access is turned on, the KeyServer will no longer demand a password from users at startup time. Instead, they will silently default to guest access and be allowed to use licenses in common pools.

Groups and License Pools

With KeyServer, you can divide the licenses for a program among multiple groups of users. Membership of a user in a group is determined in two ways: Via the active authentication method, and via the settings you make in the Network Access dialog. Certain authentication methods support group memberships for users, and you can always give a user membership in a group based on the user's network address.

For each program, you can set a list of up to 20 different license pools, each of which is associated with a specific group of users. Setting up license pools with appropriate values may take some experimentation. You may wish to monitor use of a new Control for a while, so you can adjust the counts to the optimal values. To begin with, you may find that it is easiest to set up each Control with all licenses in a single common pool.

Authentication Methods

The KeyServer will always be using one and only one of the following authentication methods at any given time:

• All Authent. All users are automatically authenticated and given access to all programs supported by the KeyServer. This is KeyServer's default authentication method. The total number of keys for each program are available to every Mac with KeyAccess properly installed. KeyAccess is all a user needs to ensure full access.
• Single Password. Users become authenticated by typing in a password, which you choose. The password is the same for all KeyServer users. Once authenticated, users are given access to all programs supported by the KeyServer. Dividing a program's licenses among pools has no effect.
• File Server. To gain access to the KeyServer, users must type the name and password that controls their access to an existing AppleShare (or AFP compliant) file server. An AppleShare file server's group information is not available remotely, so after authentication, access is granted to all licenses. Dividing a program's licenses among pools has no effect. This authentication method is only available for the Macintosh KeyServer, although clients on all platforms are supported.
• Users & Groups. To gain access to the KeyServer, users must type the name and password that controls their access to an existing AppleShare 3.0.x or higher file server. The KeyServer must be running on the same computer that is running the AppleShare server (or File Sharing). Users must belong to specific groups in order to have access to license pools. This authentication method is only available for the Macintosh KeyServer, although clients on all platforms are supported.
• Text File. User names, passwords, and groups are specified in a text file. A user becomes authenticated for KeyServer use by typing a correct name and password. Users may be members of multiple groups, and thereby gain access to license pools. This authentication method is only available for the Macintosh KeyServer, although clients on all platforms are supported.
• Kerberos. To gain access to the KeyServer, users must authenticate with a Kerberos server. Kerberos does not directly support groups, so once authenticated, users are granted access to all programs. This authentication method requires a Kerberos server on your network, and also requires a "Kerberized" version of KeyAccess.
• Windows NT. To gain access to the KeyServer, users must type their name and password as it exists in the specified NT Domain (or on the Windows NT computer that is running KeyServer). Once authenticated, users are given access to all programs supported by the KeyServer. This authentication method is only available for the Windows NT KeyServer, although clients on all platforms are supported.

For more details on the standard authentication methods - how they operate, how they determine which users are authenticated, and how they are configured - read Appendix A: Standard Authentication Methods. Sassafras is always developing new authentication methods, so contact Sassafras technical support if you do not see an authenticaion method that meets your requirements.

Configuring Authentication Methods

Authentication methods are stored in separate modules, which must be stored in the Authentication Methods folder within the KeyServer Data Folder in order to be accessible to the KeyServer. Once you have placed a module in this folder, you can instantly configure KeyServer to use that authentication method.

Authentication methods are configured through the Authentication command in the Admin menu. When you choose this command a dialog box appears that contains items and controls specific to the active authentication method. The pop-up menu on the bottom of the dialog box lets you choose from the available methods.

In the popup menu, the name of the active method appears in boldface, while the name of the method you are configuring has a check mark next to it.

Only one method may be active at a time. If you switch authentication methods while the KeyServer is running, the new method is initialized and takes effect when the initialization is complete. This process may take a minute, depending on the method, so its status is displayed in the upper right corner of the Authentication dialog box.

License pools for a Control are specified in the Licenses tab of the Control Details dialog (see Details of Controls in the KeyConfigure chapter).

The Authentication dialog is different for every authentication module. For more details on the form and function of the standard authentication modules read Appendix A: Standard Authentication Methods.

Run-time Examples

Understanding when and why KeyServer performs its authentication routines can sometimes be difficult. If the active authentication method lets some users obtain only licenses from common pools, while others can obtain all the licenses in other pools, events can be especially confusing. The situations outlined below may help clarify KeyServer's actions.

When a client computer starts up, KeyServer asks for a password. The active authentication method requires a password. If the proper password is typed, the user is authenticated; otherwise, service is denied. Like some file servers, KeyAccess can be configured to remember the name and password of an authenticated user. This way, authentication is established without the intrusion of the password dialog.

When a KeyServer-controlled program is launched, KeyServer asks for a password. If the client was disconnected from the network when it started up, and then later a KeyServer-controlled program is launched after the client computer is reconnected, the user must first establish an authenticated session with the KeyServer. When the active method requires a password, the user is asked to type it in before the controlled program continues.

When a KeyServer-controlled program is launched, KeyServer asks for a password, even though the user is already authenticated. The "Force Password" option is set for the Control, so that every time the program is launched, a password must be typed.

User A gets notified that a license is available before User B, even though User B got in line first. User A has access to a license pool that User B does cannot access. The license that was returned (and hence is available for use) is from this pool, so User B cannot use it.

There is a license available, but someone is still waiting to be notified of its availability. Similar to the previous case, the user does not have access to the pool that the returned license came from. The user will be notified when a license is returned to a pool that is accessible.