One way of using ACLs to evaluate an entity's authorization to do something is by making a call to the DCE library routine dce_acl_is_client_authorized( ). For example, there are two places in the sample application where this is done to check client access to the application's own objects:
· In sample_call( ) (in sample_manager.c)
This is an interface operation, called by the client.
· In sample_mgmt_auth( ) (in sample_server.c)
This is the remote management callback function.
Similar routines are called remotely through the sec_acl_*( ) routines.
Evaluation takes the form of a call to the procedure, passing (among other things)
· The client (that is requester's) binding
· The ACL manager type UUID
· The ACL UUID
· The desired permission set
The routine, given these parameters, is able to find and open the correct ACL database in which the ACL is held, extract the ACL, find the requester's permission set (it determines who the requester is from the credentials buried in the client binding), and compare it with the set of required permissions. If the latter can be found among the former, the routine will return a Yes answer; if not, it will return a No.
How does the library routine (especially when it is called, not from inside the application, as noted at the beginning of this topic, but, say, by acl_edit) know how to access the correct ACL database from which to extract and examine the ACL identified by the ACL UUID? The answer is that the application's database will have become known to the caller in the course of establishing a binding to the server.
This is done by calling the application's registered resolver routine; the library finds the right resolver routine by calling all the resolvers that have been registered with it until it gets a successful return. It finds the ACL manager type in the same way, since it calls each attempted resolver passing the manager type UUID that was registered with it. See the sample_resolve_by_name( ) function in the sample_server.c file.