The Basic Security Model

The following table 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.

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.

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.