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. The module manager for key recovery could be loaded on demand as required but need not be a static part of a system. User authentication based on biometric data can be an elective service. Systems where biometric devices are deployed and required only for authenticating system administrators would not need a biometric module manager as a standard, loaded component on the environment. Elective module management supports on-demand inclusion of a module manager. The module manager defines a new set of 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.
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
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 (dynamically loaded) module manager versus a basic module manager (which is always resident in the system).
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 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 dependent 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.
CSSM provides this information so CSSM and the elective module manager can effectively support the service module without the module being aware that the elective module manager was dynamically loaded and that CSSM had no prior knowledge of the structures, functions, and services provided by the service module.
CSSM provides upcall proxies to the elective module manager. When performing secure linkage checks, CSSM is aware of the EMM and verifies that the upcall originated from the service provider module or the EMM before passing the upcall on to the application.
To ensure integrity of the execution environment, CDSA recommended
that applications and service modules perform secure linkage checks of
CSSM. Elective module managers pose a problem for these checks. The
EMM's dynamic nature is transparent to the application and to the
service module, hence the EMM not included in the CSSM authentication
and secure linkage checks performed by the application or the service
provider during
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 |