Elective services extend CSSM. They define their own application programming interfaces and service provider interfaces. For example, key recovery can be an elective service. Some applications will use key recovery services (by explicit invocation) and other applications will not use it. Audit logs can be an elective service. Applications wishing to maintain a log can do so, other applications will not use that facility. CSSM's elective module management facilities provide a set of mechanisms that support runtime inclusion of new APIs and their corresponding SPIs. Standardization of the new APIs and SPIs is in addition to the current CDSA standards. The additions can be standardized as an enhancement to CDSA or as an independent standard that is adopted and used within CDSA. The elective module management mechanisms allow CDSA implementations to easily and quickly incorporate these new standards. CSSM does not have a priori knowledge of the elective APIs, but applications have complete knowledge of the new APIs in order to explicitly invoke the services provided through those APIs.
Credentials are said to carry implied authorization if they can be verified based on points of trust specified by the authorizing entity.
An elective module managers can define trust points in addition to CSSM's trust points by including application authentication keys in the module manager's description contained in its signed manifest credentials. CSSM can use these public keys as additional trust points for authenticating applications requesting exemptions. When an exemption has been granted, it is the responsibility of the elective module manager to not enforce the built-in check corresponding to the granted exemption.
To define new categories of exemption, the elective module manager defines a new, unique CSSM_EXEMPTION_MASK flag. This bitmask represents the set of exemptions requested by an application. Applications can change their exemption status multiple times during execution. Each request for exemption requires a separate authentication check .
Applications are aware of instances of add-in modules, not the module
managers that control access to those modules. Before requesting
services from an add-in service provider (via APIs defined by a module
manager), the application invokes CSSM_attach to obtain an
instance of the add-in service provider.
The dynamic nature of the elective module manager is transparent to the add-in module also. This is important. It means that an add-in module vendor need not modify their module implementation to work with an elective module manager versus a basic module manager.
There is at most one module manager for each category of service loaded in CSSM at any given time. When an elective module manager is dynamically added to serve an application, that module manager is a peer of all other module managers and can cooperate with other managers as appropriate.
Elective module management defines a set of mechanisms that support runtime inclusion of new APIs and their corresponding SPIs. Standardization of the new APIs and SPIs is in addition to the current CDSA standards. The additions can be standardized as an enhancement to CDSA or as an independent standard that is adopted and used within CDSA. The elective module management mechanisms allow CDSA implementations to easily and quickly incorporate these new standards. CSSM does not have a priori knowledge of the elective APIs, but applications have complete knowledge of the new APIs in order to explicitly invoke the services provided through those APIs. The elective module manager is responsible for checking instance compatibility with the CSSM that loaded the manager. Compatibility can be based on a combination of the CSSM's GUID, CSSM's Interface GUID, and CSSM's major and minor version number. CSSM APIs can be invoked to obtain these values. These values also represent the instance level of the basic module managers that are always present in the CSSM. In rare cases, elective module managers may have dependencies on each other. In this case compatibility between elective module managers is the responsibility of the elective module managers. These checks must be performed in a manner that does not depend on the order in which the caller attaches depend services that are supported by elective module managers. Compatibility checks among dependent, elective module managers can be checked using the event notification interface for communication among module managers. When an attached application detaches from an add-in service module, CSSM will also unload the associated module manager if it is not in use by another thread, process, or application.
When two or more module managers share state, each manager must be able to:
The other module managers must be able to:
When module managers share state information they must implement conditional logic to interact with each other. Two module managers can share state information by several different mechanisms:
The first two mechanisms depend on platform services outside of CDSA. Module managers that share state information can use all of these mechanisms.
CSSM-supported event notifications require that all module managers implement and register with CSSM an event notification entry point. Module managers issue notifications by invoking a CSSM function, specifying:
CSSM delivers the notification to the destination module manager by invoking the manager's notification entry point.
Typical event types include:
Module managers that share state information are not required to use the CSSM event notification mechanism. These types of events, requests, and notifications can be shared using the other platform dependent mechanisms. CSSM provides this simple mechanism specifically for situations where other platform services are not readily available.
| Contents | Next section | Index |