Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

Multi-Service Modules

Overview

CSSM APIs are logically partitioned into functional categories. The goal of this logical partitioning is to assist application developers in understanding and making effective use of the security APIs. To this end, the partitioning has been effective.

Vendors providing add-in security service modules are developing products that provide services in more than one functional category. Vendors may not want to partition their products in this manner. More pointedly, they can be unable to do so. Consider a class 2 PKCS#11 cryptographic device. This device performs cryptographic operations and provides persistent storage for keys, certificates, and other security-related objects. These services are logically partitioned between the CSP-APIs and the DLM-APIs. Implementing two separate add-in modules is not feasible. In order to provide correct service, the two modules must share execution state, such as PKCS#11 session identifiers. Additional examples exist, as shown in Multi-Service Add-In Module Serving Three Categories.


Figure: Multi-Service Add-In Module Serving Three Categories

Multi-service add-in modules separate module packaging from the application developers functional view of CSSM APIs. A multi-service module is a single, dynamic add-in module that implements CSSM functions from two or more functional categories of the CSSM APIs.

Application Developer View of a Multi-Service Add-In Module

Application developers require no special knowledge of the organization of the service provider modules available through the CSSM framework. Applications attach a multi-service module as they would any other module. Each call to attach a service module returns a handle representing a unique pairing between the caller and the attached module. The caller uses this handle to obtain the single type of service specified in the attach operation. A second attach of the same module for a different type of service returns a second attach handle, but does not load another copy of the service module. Separate Handles Reference a Single Multi-Service Module shows the handles for an attached PKCS#11 service provider that performs cryptographic operations and persistent storage of certificates.

Figure: Separate Handles Reference a Single Multi-Service Module

Multiple calls to attach are viewed as independent requests with respect to authorized exemptions and access control. The multi-service module can match-up the caller handles if a shared execution state is required.

Service Provider View of a Multi-Service Add-In Module

A Multi-Service Module is a single product. It has a single associated globally-unique identifier (GUID). It's implementation may consist of several libraries, forming a single service.

When an add-in module is installed on a CSSM system, the module registers its name, GUID, and capability descriptions by adding records to relations in the Module Directory Services (MDS). MDS makes this information available for application queries. A multi-service module will register capabilities for each of the service categories supported by the module.

A multi-service module is not required to implement all of the functions in any functional category. The CSSM dispatching mechanism invokes only to those interfaces registered with the CSSM.

Click here to return to the publication details.

Contents Next section Index