The SecretStore version 3.2 API includes these modifications:
SSOCOMP now allows applications to choose NCP™ or LDAP access to eDirectory without requiring transport-specific APIs. As before, the NCP protocol is only available on Windows clients and requires Novell Client™ to be present on the workstation. However, the SecretStore LDAP client can be installed on either the server or the workstation without requiring Novell Client.
SecretStore interfaces now provide faster access to the secrets in a user's SecretStore. Older versions of the SecretStore client APIs were designed to be stateless; that is, each API had to set up and tear down the connection to the SecretStore server. This approach supported regular connectors and was based on connectors' simple “per API” access to SecretStore.
As the paradigm of accessing SecretStore shifted from connectors to the universal connectors, supporting stateful sessions became necessary. Consequently, SecretStore now allows initialization at the beginning of a session by calling NSSSGetServiceInformation, then reusing the initialized state data in the context across other function calls.
All function calls are now enabled to tear down the connection and end a session upon request after the work is done. Nevertheless, the new API still supports stateless operations if no session is established ahead of time by the connector via the context. These changes to the SecretStore API architecture provide for improved performance by allowing the use of the initialized context across the calls.
In previous implementations of the API, both regular and universal connectors created overlapping secrets for the same applications in the user's SecretStore, which led to synchronization problems between the applications. For example, when a connector modified a user's credential in the target application, other connectors lost their ability to perform single sign-on for the user, and subsequently became out of sync. Consequently, connectors required user intervention to synchronize the changes made to credentials in the target application.
In addition, creating multiple secrets for common applications in SecretStore increases the number of secrets in every store. This can decrease application performance and efficiency, while unnecessarily increasing storage requirements.
To solve these problems, the SecretStore functions are now implemented as a shim layer to enable applications to process and interpret secret data that conform to the Shared Secret specification originally used by Novell SecureLogin. Connectors conforming to this set of specifications in the Shared Secret API can create secrets in the user's SecretStore that can be shared between regular and universal connectors.