Users first authenticate to eDirectory where their SecretStore-enabled applications get access to the SecretStore service. Following authentication, the application user is granted access to the enabled application services and resources without seeing a password dialog box or other authentication screens when the application starts up. It appears to the user as if access were granted automatically.
NOTE:The APIs are designed for client enablement for SSO and other methods of SecretStore utilization. The SecretStore service will be shipped as a component of all eDirectory platforms after the version 8.7.3 release.
When the user first launches an enabled application, the application's client queries eDirectory as to whether or not the user is authenticated to the directory. If the user is not authenticated, then the application's client displays the password entry dialog box. After the user enters a password, the application authenticates the user and grants access.
If the user is authenticated to eDirectory, then the client asks for the secret from SecretStore. This can be done in one of the following scenarios:
Making a call to NSSSEnumerateSecretIDs or directly to NSSSReadSecret indicates whether or not this is the first time SecretStore has been accessed for the application. If the Secret ID is returned by the call to NSSSEnumerateSecretIDs, the application can then proceed by calling NSSSReadSecret and using the returned secret to log in the user to the application. A successful direct call to NSSSReadSecret returns the secret for the application.
If these calls denote failure or a non-existent Secret ID, the application prompts the user for authentication. If the user successfully authenticates, the application uses the authentication information in calls to NSSSWriteSecret to create and populate the user's SecretStore for the next time (the user launches the application).
The NSSSEnumerateSecretIDs function provides the method for applications with multiple login IDs to select the proper authentication method. Applications can then have the necessary configuration information to define a default login in case of multiple IDs.
As an alternative for populating the SecretStore for the first time, NSSSWriteSecret can be used with the proper flag to check for ID collision or to bypass the check and overwrite the secret if it already exists in the SecretStore. Use the NSSS_CHK_SID_FOR_COLLISION_F flag to enable NSSSWriteSecret for collision checking.
The first time a user authenticates to an application, no secret is available through SecretStore for that application, and the user is prompted to enter a password. Upon successful authentication to the application, the user is granted access and the application authentication information and secret is stored in an encrypted format in the SecretStore for subsequent use.
In the case of password administration where users are required to change their passwords after a certain number of days, a user doesn't need to remember a password that hasn't been recently used. This is done by enabling the password update code section in the application. SecretStore can retrieve and supply the old password to the application. The user then enters only the new password.
After the user changes the password, the new secret is captured and encrypted. The application then calls NSSSWriteSecret to overwrite the existing secret, which updates SecretStore with the new credentials. This ensures seamless operation the next time the user launches that application. If the shared secret calls are used here, the secret is updated in a format that allows all applications to use the secret and retain synchronization.
A user can use the Novell ConsoleOne management utility Version 1.3 or newer, in addition to SSManager.exe, to recall forgotten passwords or view secrets stored in the SecretStore. The Novell iManager™ plugin also can be used for SecretStore management.