2 — Technical Overview

[Previous] [Next] [Contents] [Index]

This chapter provides a technical overview of CAS, and contains the following sections:

2.1 Components
2.2 Co-Authentication Process

2.1 Components

Figure 2-1 shows the general client and server components required by CAS:

Figure 2-1: Client and Server Components

The client system requires:

PC-DCE Client — This is the full client (daemons configured).
Login Program — Provided by the developer. The login program implements certain functions required by CAS and provides client support for each desired authentication method.

The server system requires:

Gradient Security Server — The Gradient Security Server provides a generalized CAS interface that supports user-developed authentication methods implemented as Co-authentication DLLs (see the following item). The Gradient Security Server is the PC-DCE Security Server with NetCrusader extensions installed.
Co-Authentication DLLs — The developer implements each desired authentication method as a DLL written to the CAS interface.
Registry Database — The registry database provided by the PC-DCE security server includes entries for all principals (users) to be authenticated through CAS. Each principal entry that will use CAS requires an extended registry attribute (ERA) that lists the authentication methods allowed for this principal.
cass_handlers — Text file that the security server reads to identify the authentication methods supported on this server and the associated DLLs.

2.2 Co-Authentication Process

For each login session, CAS uses an initial solicit phase to determine the authentication method to use. The solicit phase is followed by a challenge/response phase during which the user is prompted to supply authentication data, and the appropriate co-authentication DLL verifies the data.

2.2.1 Solicit Phase

To prepare for the solicit phase:

The client login program obtains the user's principal name and builds a client-supported method list. To build the list, the login program calls the CASAPI function casc_prompt_register() for each supported authentication method. This function identifies the authentication method (by UUID) and registers required callback functions that the PC-DCE client runtime calls during the challenge/response phase.
The Gradient Security Server identifies all installed co-authentication DLLs and builds a list of server-supported authentication methods. It identifies the installed co-authentication DLLs by reading the cass_handlers file, which contains a list of DLL names. The Gradient Security Server builds the server-supported method list by calling the cass_get_type() function exported by each co-authentication DLL. This call returns a UUID that identifies the authentication method that the DLL supports.

To begin the solicit phase:

The client login program calls sec_login_validate_identity(). This starts CAS within the PC-DCE client runtime. The PC-DCE client sends the Gradient Security Server a solicit message containing the principal's user name and the client-supported method list.
The Gradient Security Server determines which method it should use by examing the principal's CASAUTHSVCS ERA, which is a prioritized list of co-authentication DLL names. It chooses the first method (DLL name) in the ERA list that is supported by both the server and the client.

2.2.2 Challenge/Response Phase

In the challenge/response phase, the Gradient Security Server calls the following CASAPI functions exported by the selected co-authentication DLL:

cass_initialize() allows the DLL to load whatever it needs (such as another DLL) and set up any required environment parameters.
cass_response() returns the initial challenge data. The Gradient Security Server can then send the client a reply to the initial solicit request. This reply identifies the selected method and includes the initial challenge data for that method. This begins the challenge/response phase. Note that it is possible for cass_response() to return a value of login complete (see below) which would automatically log in the user without verification.
cass_response_free() allows the DLL to clean up the challenge data (free memory) once the security server is finished with it.

The PC-DCE client runtime calls the callback function (type casc_routine_t defined in casc_proto.h) that handles challenges and responses for the selected authentication method. The PC-DCE client runtime passes the challenge data to this function and collects the user response as an output. The PC-DCE client runtime sends the user's response back to the server and calls the callback function (type casc_routine_free_t defined in casc_proto.h) to clean up the response data.

The Gradient Security Server calls cass_response(), this time supplying the response data from the user. This returns one of three values:

challenge — The DLL wants to send another challenge to the user and has provided the challenge data. The server sends the challenge to the client. When it receives the response, it calls cass_response() again. The challenge/response cycle continues either until login completes or login fails. After each cycle the server calls cass_response_free().
login complete — The DLL successfully authenticated the user. In the client login program, sec_login_validate_identity() returns TRUE.
login fail — The authentication failed. In the client login program, sec_login_validate_identity() returns FALSE.

2.2.3 Cleanup

When the challenge/response phase is complete, the PC-DCE client calls the callback function (type casc_routine_session_free_t defined in casc_proto.h) to clean up any session data.

When the Gradient Security Server is shutting down, it calls the cass_terminate() function, which allows the DLL to perform any final cleanup.