OSF DCE Application Development Guide--Introduction and Style Guide
OSF DCE Application Development Guide—Introduction and Style Guide
that object UUID binding happens only once in an uninterrupted client/server session;
after the partial binding is completed, communications proceed directly between the
client and server. Type manager vectoring, on the other hand, occurs every time an
incoming RPC contains an object UUID.
The very different nature of the two mechanisms just discussed is somewhat obscured by
the order in which they are initialized in the steps in this chapter. The following list
shows the relevant server steps, with an indication in each instance to which mechanism
they are related:
1. When setting up the server’s objects, groups of object UUIDs are associated under
type UUIDs in the RPC runtime related to the type vectoring mechanism.
2. When defining the manager EPVs, each type UUID is associated with a manager
EPV (in the RPC runtime) related to the type vectoring mechanism.
3. When registering the server, object UUIDs and server endpoints are registered
with the server’s endpoint mapper and the server bindings (containing the object
UUIDs) are exported into the namespace. These are related to the endpoint
mapping mechanism.
1.5.3 Setting Up Security
To set up the security environment, the server makes the following DCE library call:
dce_server_sec_begin(dce_server_c_login | dce_server_c_manage_key, \
&status);
The flags in the first parameter represent the following security issues:
• Establish the server principal identity
When first invoked, a server process uses the login context of the user who invoked
it, until it assumes its own identity by accessing its secret key, which is analogous to
a user’s password, and using it to get its own login context. Of course, it is possible
for a server to simply continue using its inherited login context. In that case, all it
needs to do is use the security login routines to obtain its principal name and
explicitly get its login context.
• Manage the server key
When a server has its own identity, it takes on responsibility for the upkeep of its
password using the security key management routines.
The decision whether or not to use authenticated remote procedure calls is something of
a cooperative matter between the client and the server. When the client calls
rpc_binding_set_auth_info(), it registers its preferences about the same things. The
client’s and server’s choices are not required to agree in order for the client to
successfully reach the server. If the client’s authentication and authorization choices do
not agree with what the server expects, it is up to the server to decide whether or not to
go ahead with the operations, and how far to cooperate with client requests.
1− 18 Tandem Computers Incorporated 124246