How DCE Security Works
This topic gives an overview of how the DCE security services and facilities interact to provide a secure distributed computing environment. The following figure shows this process. The presentation in this section is a simplified view of the transactions that actually take place.
DCE Security Interactions
When a DCE cell is first created, the DCE security administrator runs a program to create an initial DCE security database. The administrator then starts up a DCE security server, called secd, on the same machine as the database. Using the dcecp program, the administrator creates user accounts in the security database.
After the administrator has created an account for a user, the user can participate in a secure DCE system. Typically a user logs into the account at the beginning of a session. The login facility interacts with both the authentication server and the privilege server. It sends a request for authentication credentials to the authentication server. The authentication server sends back the authentication credentials, called a ticket. The authentication server's reply is encrypted using the user's password, so if the user can supply the right password, the reply can be decrypted and the ticket can be accessed. Tickets are used by clients to authenticate themselves to servers; that is, to prove that clients are really who they say they are.
Next, the login facility sends the ticket to the privilege server. The privilege server returns authorization credentials, called an extended privilege attribute certificate (EPAC). The EPAC contains authorization information specific to the user, such as which groups the user belongs to. EPACs are used to authorize users; that is, to help a server decide whether users should be granted access to resources that the server manages. When the login facility has finished running, the user has a security environment and can communicate in a secure way with application servers.
For example, if the user runs an application client, the application client can use authenticated RPC to communicate with the application server. The application server receives the RPC-based request, which includes the user's EPAC. The server inspects the user's authorization credentials and the Access Control List associated with the resource the user wants to access. If, for example, the ACL says that any user in the group friends can access the resource, and the user's EPAC shows that the user is in the friends group, then the server will give the user access to the resource.
The authentication and authorization information that is sent over the network is all encrypted so that only the intended recipients are able to decrypt and read the messages. If desired, the application data can be encrypted as well. This prevents any unauthorized user from being able to read data that is sent over the network.
The encryption used in DCE is secret key encryption, in which two parties share a secret - the encryption key. Using that key, they can encrypt and decrypt each other's messages. (For information on the generation, transfer, and use of encryption keys in DCE security, see the security topics of the OSF DCE Application Development Guide - Introduction and Style Guide and OSF DCE Application Development Guide - Core Components.
Finally, although it is not shown in the figure entitled DCE Security Interactions, all the security service events just discussed - creating a user, logging in, obtaining a ticket, and so on - are recorded and logged in an audit trail file by the audit service daemon, auditd. In addition, if the application server has been designed to use the audit service, and the operation that the application client is requesting has been designated an audit code point, then the audit service logs the execution of the server operation on behalf of the requesting client.