The Requirements

· There must be a procedure that can take the valid name of an object and return that object's ACL UUID to a caller. This typically is accomplished by (first) looking up an object UUID in a name-indexed database and then (secondly) extracting the ACL UUID from the object state information, which was looked up in a database indexed by object UUIDs. The databases, of course, must be set up and maintained by the application. Clients to bind to the objects through a CDS junction at the server's entry.

· The application's object name resolver has to be registered into the DCE runtime remote ACL (rdacl) interface mechanism, so that the DCE routines (such as sec_acl_bind( )) and the acl_edit command can access it.
This is the server object name resolution procedure described in item 1. acl_edit accepts a (CDS entry) name which it expects to be able to resolve into an object which has an ACL it can access. For this to be so, the application server must register a routine (with the rdacl interface UUID) which, when called by acl_edit with an object name, will be able to return to acl_edit the information it needs (that is, a UUID) to get the ACL itself. In other words, the routine must be able to turn an object name into an ACL UUID.

· A persistent database in which to store the ACLs must be created. (The database must be compatible with the interface that the security routines use; that is it must be created with the DCE backing store library routines.)

· The ACL database must be registered (together with a manager type UUID and a name-to-ACL UUID resolver procedure) with the ACL library.

· An object type (that is, manager type) UUID must be created to identify each of the application's ACL categories (that is, the kind of object the ACL applies to, and hence the kind of ACL itself: what permissions it can contain, and what they mean in regard to the object they protect). (The manager type will also serve as an identifier for the ACL database that the ACLs themselves are stored in - this however is internal to the ACL library.)

· UUIDs to identify the objects must be created.

· The ACLs themselves on the relevant objects must be created.

· The ACLs must be stored, indexed by UUID, in the backing store database.

Setting up an ACL manager is a matter of making these eight things happen. The sample application shows the easiest way of accomplishing this, namely by using the DCE ACL library. See in particular the routine server_acl_mgr_setup( ) in sample_server.c.

Note, by the way, that discussing the details of setting up an ACL manager without first considering the representation and management of the objects themselves is a very artificial thing to do. The excuse for doing it here is that ACL managers are the subject of this topic. However, keep in mind that ACLs are only an adjunct to the objects they guard access to. In a real application one would never put the cart before the horse by working out the details of ACL management before settling on the way object management itself was to be done.