PreviousNext

Preparation

What the client essentially wants to do now is call the routine rpc_binding_set_auth_info( ) in order to specify all the necessary security parameters. However, when it does this, it should be able to specify its server's principal name, so that the server it binds to can be authenticated to the client. (The server's principal name is the name by which the server is known to the DCE Security Service.) The client must also supply a handle to its own login context when it calls rpc_binding_set_auth_info( ).

There are several ways to determine the server's principal name, as follows:

· The server's principal name could be hardcoded in the client. This is not recommended practice for reasons of robustness and flexibility.

· The client can be handed the name as input from the command line when it is invoked.

· The principal name can be the same as the name entry (binding information) name.

· The client can query the server's principal name by calling rpc_mgmt_inq_princ_name( ). It can then check group membership by calling sec_rgy_pgo_is_member( ), using a known tested group.

The reason for checking group membership has to do with authorization-related decisions that the client may need to consider. It is not necessarily enough to know that a server has a certain identity; it may also be necessary that it belong to a certain group in order for it to be fully authorized, from the client's point of view, to receive the data that the client will send. In other words, the client may need to make a decision about the server similar in nature to that which the server makes about the client, when it checks the client's authorization, via ACLs, to do the things it wants to do. Security can be just as important for the client as for the server; this is the justification for having to make the extra calls described here.

The client retrieves its login context with the following security library routine:

sec_login_get_current_context(&login_context, &status);

However, this is not usually necessary. The client can, by passing a NULL value to rpc_binding_set_auth_info( ), simply use its default login context.

In any case, note that this login context already exists; the client merely retrieves it. (The client inherited its login context from the user principal who executed it.) The client can now set up for authenticated RPC.