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.
To control access to the server's objects, ACL managers are also set up.