OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming

1.7 The Server’s Manager of RPC Requests

As was explained, server threads are automatically spawned by the RPC runtime in the

server manager to handle incoming remote procedure calls from clients. The number of

calls that can be concurrently handled depends on the value of the max_calls_exec

parameter speciﬁed in the call to rpc_server_listen(). The thread is created by the RPC

runtime and begins execution in the operation requested. When the operation is

completed, the thread is automatically terminated (by the RPC runtime).

See also the and the OSF DCE Application Development Reference for a

comprehensive discussion of DCE threads.

1.7.1 Getting the Client’s Credentials

As mentioned in the previous step, authentication, if it was speciﬁed by the client, has

already occurred if the client’s request is received by the server manager. If the client

fails to authenticate itself to the server runtime, its remote procedure call fails before

reaching the server’s RPC code.

Authentication, if speciﬁed by the client and offered by the server, is performed by the

RPC runtime; it is not a responsibility of the application code. However, it is up to the

application to formulate its own security policy with regard to the client, based on the

following:

• The level at which the client has been authenticated.

• The client’s authorization; that is, whether the client should be allowed to access

resources it may request.

In order to ﬁnd out the client’s authentication and authorization information, the server

calls the following RPC library routine:

rpc_binding_inq_auth_caller(binding_handle, privs, server_princ_name,\

protect_level, authn_svc, authz_svc, &status);

The parameters in this call are analogous to the similarly named parameters in the

registration routines. The server can learn what level of authentication, what

authentication service, and what server principal name the client speciﬁed. Of most

interest, however, are the privs and authz_svc parameters. The privs parameter is a

pointer to whatever information the client is willing to let the server know about its

privilege attributes; authz_svc tells what this information is. It could be any one of the

following:

• The client’s privilege attribute certiﬁcate (PAC), containing the client’s principal and

group UUIDs. These can be used to look up the client’s privilege attributes in ACLs,

whose entries are keyed by principal and group UUID.

• The client’s principal name (a string). This also can be used to look through ACLs,

provided that the lists have been annotated with such name strings.

124246 Tandem Computers Incorporated 1− 31