OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
3.1 The Basic Security Model
At a high level, the DCE security model is as follows. Servers specify the authentication
service they use (currently either none or DCE secret key). Clients request an
authentication service (which may be none) when making a call. When a server specifies
an authentication service, it is specifying the service it will use if authentication is
requested by the client. This allows a server to permit both authenticated and
unauthenticated access. When a client requests authentication and the server provides it,
authentication is carried out silently by the runtime as part of the RPC protocol. The
runtime will fail the call if the client cannot be authenticated. When no authentication is
requested, none is performed. If the client requests authentication and the server does
not provide it, the runtime will fail the call.
Table 3-1 shows how client and server authentication actions affect RPC calls. Clients
specify an authentication service for a binding handle by calling
rpc_binding_set_auth_info(). Servers register an authentication service by calling
rpc_server_register_auth_info(). The possible values are rpc_c_authn_none for no
authentication and rpc_c_authn_dce_secret (or rpc_c_authn_default) for DCE secret
key authentication.
TABLE 3-1. Authentication
__________________________________________________________________________
Client Specifies Server Registers Authentication
__________________________________________________________________________
__________________________________________________________________________
rpc_c_authn_none rpc_c_authn_none No authentication performed
__________________________________________________________________________
rpc_c_authn_none rpc_c_authn_dce_secret No authentication performed
__________________________________________________________________________
rpc_c_authn_dce_secret rpc_c_authn_none Call rejected by RPC runtime
__________________________________________________________________________
rpc_c_authn_dce_secret rpc_c_authn_dce_secret Authentication performed
__________________________________________________________________________
Authentication establishes only that each of the parties is a principal known to the
authentication service, and that each party knows who the other is. Servers typically
make an explicit authorization decision using one of the DCE authorization services, to
decide whether a given authenticated principal should in fact be granted access to some
operation or resource. In most cases, clients will not be satisfied with the mere assurance
that they are communicating with an authenticated principal. Clients must then check
the authenticated identity of the server to be sure that it is one with which they are
willing to communicate. Note that this kind of server identity check is normally made at
a low level of granularity: typically once per client-server session. Server authorization
of clients is usually much more specific: typically once per remote operation.
Authorization is based on the identity of the caller, which may be expressed either as a
principal name or as a set of privilege attributes. What the RPC authentication model
provides to the server are, essentially, guarantees as to the authenticity of the identity,
and possibly, the privilege attributes of the caller. Since an identity without such
guarantees would be useless for access checking, authorization is supported only for
authenticated RPCs. If the client chooses to call unauthenticated, the runtime permits
the call and does not provide any authentication information.
3− 2 Tandem Computers Incorporated 124246