OSF DCE Application Development Guide--Introduction and Style Guide

Security
It is entirely up to the application manager code to make an access decision based on any
authentication and authorization data provided by the runtime for a client. Clients
specify an authorization service for each binding: either none (rpc_c_authz_none),
client principal name-based authentication (rpc_c_authz_name), or DCE credential-
based authentication (rpc_c_authz_dce). When a server manager operation is invoked
(implying either that no authentication was performed or that authentication was
performed and succeeded), the application can retrieve any authorization information by
calling rpc_binding_inq_auth_caller().
The application manager must then make an access decision based on the retrieved
information. The DCE ACL facility provides applicaton support for ACL-based
authorization using the client credentials. This is the recommended authorization
scheme.
In addition to authentication and authorization, the DCE security services can also
provide various levels of data secrecy and integrity guarantees. The basic model is that
the client application requests the minimum acceptable protection level. The runtime
then provides the lowest supported protection level that is at least as high as the one
requested by the client. If the runtime cannot provide at least the requested level, it fails
the call. Supported levels as well as the services provided by each level depend on the
authentication service in use, so clients must take care to request a level that is
meaningful for the authentication service they have specified.
3.2 Application Roles
Each of the elements of DCE security makes very different demands on the application.
In the case of data protection, the application need only specify a protection level. The
RPC runtime takes care of data protection transparently and the guarantees provided are
fairly easily understood.
In the case of authentication, clients and servers have to do more work to establish the
required state for authentication to take place. The required steps are described in detail
in Section 3.3 of this chapter. Once this initialization is taken care of, the RPC runtime
provides authentication transparently.
The authorization component of DCE security requires the most work from the
application. Essentially, DCE provides applications with a set of mechanisms for access
control. These include the following:
• The authenticated identity and privilege attributes (in the form of credentials) of
service requesters, provided by the RPC runtime to servers.
• ACLs which servers may associate with objects they control.
• A default mechanism for determining a service requestor’s privileges from an ACL
and the requestor’s credentials.
• Tools for administering ACLs.
Servers that use the DCE ACL-based authorization services must do a fair amount of
initialization to create an ACL manager. Each protected operation must then explicitly
call the ACL manager to make an authorization decision for each protected operation. A
124246 Tandem Computers Incorporated 3−3