Client Authentication
Typically used for automatic division mapping, more complex workstation authentication is possible.
Authentication is one of the most powerful features of the Sassafras KeyServer Platform, but it is also one of its most complex. While it can greatly enhance management of programs, authentication can also make the configuration process more involved. Before using the authentication features of KeyServer, carefully read this page. For documentation on options and configuration of each specific type of authentication that is available, consult the Authentication Modules documentation. For logging in to KeyConfigure or the Web UI, see Admin Authentication.
For most purposes, license management and reporting based on the computer ID and Division membership is completely adequate. Access to KeyServer and individual policies can also be based on the IP address of the client computer. Before you consider adding an authentication requirement (i.e. changing from "Disabled" to one of the modules below), check the documentation on how to define Divisions and Groups based on computer ID alone and how to use Locations to set up location-based access restrictions.
In some environments, the licenses you are managing may require access to be managed in ways that go beyond network location. For example, a KeyServer might be configured to restrict access to specific user accounts that must be authenticated by name and password. Or perhaps access and license policies need to be restricted to specific computers based on division or group membership conditions. Membership in a group may be determined solely based on the settings you make in the Group Details Window or in combination with data accessed through an authentication module (e.g. by Active Directory). Using the Group Details window alone you can control membership by individual computer, computer Division, network address, or a filter on additional properties of the computer. Thus, restrict a policy to an intricately configured scope even without using authentication. However, for greater flexibility or when account credentials and groups have already been defined externally, configuring an appropriate authentication module may be the best way to achieve your license management goals.
Authenticated vs. Guest access
The process a client follows to gain access to your KeyServer is called authentication. Once the user (or computer) has passed the required test (e.g., typed the proper password), the session is authenticated. A session is not authenticated if the login attempt fails to satisfy some requirement of the active authentication module (e.g., fail to type an acceptable password). But if a user tries to connect to the KeyServer from a location that is not allowed, KeyServer will not even progress as far as the authentication step. The choice of authentication module and the configuration of the Guest option is irrelevant to logon attempts from a prohibited location.
From the Config Menu, the "Client Authentication..." menu item is used to select an authentication module and configure its various options. The "Disabled" method is the default, meaning there is no authentication requirement at all. With an actual method chosen, the configuration dialog box displays both general client authentication and module specific Configuration options:
Note: the check box for "Assign Division automatically" is always displayed even when this option doesn't make sense as in the Single Password method illustrated above.
Sessions that do not satisfy the conditions specified by the module and its configuration will be denied access to KeyServer services – unless the allow “Guest” logon option is checked so that for members of the specified group, the module will not even be invoked. For example, guest logons might be allowed within an "on campus" Group so that no password will be requested. But from outside, the authentication module will instruct the client component, KeyAccess, to display a name and password dialog – the login session will only be allowed to continue if the values entered are successfully authenticated.
Note: the group that is referenced by "Allow Guest Logon" (e.g. "on campus" in the dialog above) must be an internally defined group. It can't be defined externally by the authentication service itself since guest group membership is designed to preclude even invoking the authentication module. However, if an application is launched on a computer with a guest session, and a Policy managing this application references an external group in its scope, then the authentication module will still be invoked – and perhaps a password will be demanded at launch time in order to determine if the computer is "in scope". Also, any Policy with the Force Password option enabled will invoke the authentication module and demand a password at every launch of applications under its management.
Assign Computers to Divisions Automatically
Some authentication services such as Active Directory may include information about which division each computer belongs to. Assuming that you intend to adopt the same meaning for the Divisions appearing in the Computers window, it may be convenient to automatically populate these Divisions with the appropriate computers based on this external information – use the checkbox, "Assign Divisions Automatically". If the authentication service attempts to assign a new computer record to a Division that has not already been defined in KeyServer, you may want to also enable the "Create Divisions as Needed" option – otherwise the new computer record will remain "uncategorized". For increased flexibility, disable the option for mapping to take precedence over Rules. The radio buttons higher up allow you to choose which OUs to use in the mapping in the case of AD. Using All is recommended for creating a full layout as you see in the AD, rather than just the top or bottom level of the path. Reverse order actually means they will show in the normal GUI way (remember that at command line OU structure is "backwards").
When automatic assignment is not checked or is not relevant for the chosen authentication method, new computers will be assigned to "Uncategorized". Note: Just like any Rule filter that assigns a division, the automatic assignment based on an authentication method only effects computer records that are not Anchored. Once a computer record has been Anchored, its division membership will no longer be subject to automated division assignment.
Example Scenarios
Allow everyone to connect, and don't use authentication for group membership.
Use the default authentication choice, Disabled.
Restrict who can connect using an authentication module, but don't use its group definitions.
Use any authentication module besides the default, Disabled. The module may or may not support groups. Make sure Allow Guest.. and Assign Divisions... are disabled.
Allow everyone to connect, but use authentication for group membership.
Use an authentication which supports groups. Enable guest access so that even those who do not have a name and password can still connect (but will not be authenticated into any groups). Optionally enable Assign Divisions ... so that scope restriction based on division can be used even for guest sessions.
Restrict who can connect, and use authentication for group membership.
Use an authentication which supports groups, and make sure Allow Guest... is disabled, so that only those who are successfully authenticated can connect.
Partial Guest Access
This is the example explained in the Authenticated vs Guest section above where "on campus" sessions are allowed as guests without authenticating, but outsiders must enter a name and password. Specify the desired group for allowing unauthenticated logons using the drop down menu to the right of the Guest Logon... checkbox.
Run-time Examples
Understanding when and why KeyServer performs its authentication routines can sometimes be difficult. The situations outlined below may help clarify KeyServer's actions.
When a client computer starts up, KeyServer asks for a password.
The active authentication module 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-managed 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-managed program is launched after the client computer is reconnected, the user must first establish an authenticated session with the KeyServer. When the active module requires a password, the user is asked to type it in before the managed program continues.
When a KeyServer-managed program is launched, KeyServer asks for a password, even though the user is already authenticated.
The Force Password option is set for the Policy, so that every time the program is launched, a password must be typed.
User A gets notified that a policy is available before User B, even though User B got in line first.
User A has access to a policy 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.
Choosing an Authentication Method
Authentication modules installed in the KeyServer Data Folder are available to use for both Client Authentication and for Admin Authentication. Client and Admin Authentication can be configured to use the either the same or different modules, but each of these services relies on just one module – if you switch authentication modules while the KeyServer is running, the new module will momentarily delay taking effect until its initialization phase is completed. Note: configuration of any authentication module can be performed using KeyConfigure running on either Windows or Macintosh, but not all modules are available for every KeyServer host platform – e.g. the Active Directory module is only available when KeyServer is hosted on Windows.
Consult the Authentication Modules documentation for a description of options and configuration steps for each specific module choice.