Previous section.

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

Introduction

CDSA Add-In Module Overview


Figure: CDSA Add-In Module Structure

A CDSA add-in module is a dynamically-linkable library, composed of functions that implement some or all of the CSSM Module Interfaces. Add-in module functionality is partitioned into two areas:

Add-in modules provide one or more categories of security services to applications. The service categories are Cryptographic Service Provider (CSP) services, Trust Policy (TP) services, Authorization Computation (AC) services, Certificate Library (CL) services, and Data Storage Library (DL) services. Each security service contains one or more implementation instances, called sub-services. For a CSP service providing access to hardware tokens, a sub-service would represent a slot. For a CL service provider, a sub-service would represent a specific certificate format. These sub-services each support the module interface for their respective service categories.

This Part describes the module interface functions in the AC service category.

Each module, regardless of the security services it offers, has the same set of administrative responsibilities. Every module must expose functions that allow CSSM to indicate events such as module attach and detach. In addition, as part of the attach operation, every module must be able to verify its own integrity, verify the integrity of CSSM, and register with CSSM. Detailed information about add-in module structure, administration, and interfaces can be found in Part 9 of this Technical Standard.

Authorization Computation Overview

An application or service that applies access control is typically faced with a request of the form:

"I am subject S. Do X for me."

The code performing the access control needs to answer two questions before performing this action:

  1. Is this subject S?

  2. Is S allowed to do X?

The first is called authentication. The second is called authorization.

There are many forms of authentication. These forms and the mechanisms that support them are covered in other sections of this specification.

No authorization decision can be traced back to a universal truth. Instead, it must be based on some assumption(s). Each assumption is formalized in an Access Control List (ACL) structure. An ACL is a list of subjects allowed to have some particular access to some resource. A requestor presents a Requested Subject corresponding to the subject of an ACL. The Requested Subject can be matched with the subject of an ACL, which grants rights to the subject. Certificates, Requested Subjects, other forms of credentials, and ACLs (which are non-signed credentials) can all be involved in the authorization decision.


Click here to return to the publication details.

Contents Next section Index