OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide

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 ﬂexibility.

• 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 justiﬁcation 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.

1.6.2.2 Setting Up for Authenticated RPC

The client makes the following call in order to set up the security characteristics of the

communications it is about to enter into with the server:

rpc_binding_set_auth_info(binding, server_princ_name, protect_level,\

authn_svc, login_context, authz_svc, &status);

The security parameters speciﬁed here include protect_level for level of protection

performed (for example, authenticate only at the beginning of each RPC, or authenticate

everything received by the server), authn_svc for the authentication service (including

‘‘none’’), and authz_svc for the type of client authorization information that will be

supplied to the server.

1− 28 Tandem Computers Incorporated 124246