How SecretStore Works

SecretStore 3.3.3 runs on AIX, Linux, Solaris, HP-UX, NetWare 5.x, NetWare 6, and Windows 2000/NT.

The UNIX servers require Novell eDirectory 8.7.1 or later. (NICI is automatically installed during server installation.)

The NetWare 5.x and NetWare 6 servers can run NDS 7, as long as NICI 2.4 or later is installed. However, we recommend that you upgrade to Novell eDirectory 8.5 or later.

Windows NT/2000 servers require eDirectory 8.7x and NICI 2.4 or later. The following figure illustrates SecretStore running on these platforms:

When you install SecretStore on these servers, the installation program installs the SecretStore service on top of eDirectory and NICI. SecretStore plug-ins run on top of SecretStore.

The following figure illustrates the server NCP and LDAP protocol stacks on a server platform:

The following figure illustrates the client NCP and LDAP protocol stacks on a client workstation:

The following figure illustrates the SecretStore client and server architecture in Java*:

SecretStore plug-ins include client APIs, NCP, and an LDAP extension.

You install administrative and SecretStore components on a Windows workstation and administer SecretStore from there.

The following figure illustrates client software running on a Windows workstation:

The following steps illustrate how SecretStore works:

1. A user logs in to eDirectory by using a password.
2. A successful login allows the user's secrets to be downloaded (when necessary) from SecretStore to the workstation.
3. The user accesses a client-, Web-, or host-based application. The connection recognizes the application and responds with the appropriate username and password from SecretStore.

   If the connection does not discover matching credentials, the client prompts the user to add the application. Secrets are synchronized when certain events occur or when the user connects to or disconnects from eDirectory.

Single Sign-On Authentication Process

The figures below describe the process of single sign-on authentication and show how an enabled application can interface with SecretStore, read and write secrets, and authenticate the user.

Authentication without SecretStore

For purposes of comparison, the following figure illustrates how a user might authenticate to a network application that isn't enabled for single sign-on.

1. The user runs a network application.
2. The application calls the authentication module.
3. The module prompts the user to log in. The user submits credentials (for example, a user ID or smart card) and secrets (for example, a password or PIN), then authenticates.
4. The authentication module notifies the application that access has been granted.
5. The user starts interacting with the application.

Initial Authentication to a SecretStore-Enabled Application

The following figure illustrates the first-time authentication to an application that has been enabled for single sign-on with SecretStore.

1. The user runs an enabled network application.
2. The application calls the authentication module.
3. The module prompts the user to log in. The user submits credentials (for example, a user ID or Smart Card) and secrets (for example, a password or PIN), then authenticates.
4. The authentication module updates Novell SecretStore with the user's verified authentication information.
5. The authentication module notifies the application that access has been granted.
6. The user starts interacting with the application.

Subsequent Authentication to a SecretStore-Enabled Application

The following figure illustrates the processes involved in subsequent user authentication to a single sign-on enabled application using SecretStore.

1. The user starts interacting with the application.
2. The application calls the authentication module.
3. The authentication module calls Novell SecretStore to retrieve the user's authentication secrets.
4. Novell SecretStore returns the user's authentication secrets (identification, secrets, etc.) to the authentication module, and the user is authenticated.
5. The authentication module notifies the application that access has been granted.
6. The user runs a single sign-on-enabled network application.