As mentioned in the previous step, authentication, if it was specified 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 specified 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 find 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 specified. 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 certificate (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.
· Nothing. The client chooses not to provide any authorization information.
From now on, it is the server's decision, as implemented by the developer, how to respond to the client's requests for services and resources, depending on the security information the server has learned about it. A non-ACL-based strategy may be implemented using the client's principal name string for lookups. The ACL-based strategy, which is supported by a DCE interface, is described further in the next step.