The SecretStore client library must be able to locate a SecretStore server that can service its requests before any operations can be performed. A server is only able to service a request from the client if it meets these criteria:
The service discovery process used in the SecretStore API avoids the shortcomings of methods available in earlier versions of the service. In addition, it provides additional flexibility by allowing the administrator to specify a particular set of service configuration parameters that should be used when accessing the SecretStore service.
This section contains the following topics:
A new attribute, sssSingleSignonConfigDN, has been designated for specifying the distinguished name of the SecretStore object that contains the configuration parameters the user should use. The administrator can add this attribute to user objects and containers. During service discovery, the client uses this attribute in its attempts to find a server that supports the specified configuration settings, as described below.
When the SecretStore service is loaded on a server, it builds a cache of the available configurations for different containers it can support (defined by the administrator). This cache can be built using a command line parameter telling it the distinguished name of a SecretStore override object that should be used for obtaining configuration parameters (see NSSSGetServiceInformation and NSSSReadSecret for a description of these parameters).
While loading, the service adds a special service information attribute to the root of its partition. This attribute contains the distinguished name of the server, its IP address, and the distinguished name of the specified configuration object, if any. When the service is unloaded, it removes this attribute from the root of the partition. Using this technique, clients have a well-known location where they can find information about available SecretStore servers that can possibly support their configuration.
To locate an acceptable SecretStore service, the client first determines if the specified user should use a particular configuration by looking for the sssServerPolicyOverrideDN attribute on the user object and its parent containers. When this attribute is found, the distinguished name of the specified configuration object is read into memory.
Next, the client reads the service information attribute (added by SecretStore services while loading) from the root of the partition. It then looks at each value of that attribute for a server name that has a matching configuration object's distinguished name (if one was found on the user object or one of its parent containers). If no configuration object distinguished name is required, any server in the list will match.
As soon as a matching entry is found, the client pings the server to see if it is available. If not, it continues looking at attribute value entries and pinging servers until a server is found that responds, or until it has exhausted all attribute value entries.
Using this method, the client avoids the need to traverse the Directory tree looking for servers that contain a writable replica of the partition. Also, the administrator can configure objects that use SecretStore in such a way as to prevent unnecessary traffic over expensive WAN links.