There are two questions that DCE security can answer for a principal about another principal with which it might want to communicate:
· Is this principal really who it says it is?
· Does it have the right to do what it wants to do?
Depending on the answers to these questions, a security-sensitive principal takes different courses of action with respect to a principal with which it is communicating.
To authenticate a principal means to verify that the principal is representing its true identity. To authorize a principal means to grant permission for the principal to perform an operation. While distinct, the concepts of authentication and authorization are also intertwined. For one thing, a principal's authorization is explicitly linked to its identity. For another, there is the possibility that authorization data concerning an authenticated principal can be falsified, which raises the additional question, "Should the authorization data concerning this principal be believed?'' To this question also, DCE security can provide an answer to a principal for which this issue is a concern.
The discussions of authenticated RPC refer to the specific mechanisms by which authentication and authorization are performed as authentication and authorization protocols. Authenticated RPC supports at least one of each. However, RPC documentation refers to authentication and authorization protocols as services. The security topics use the term protocol instead of service in this context to prevent confusion between the protocol-independent DCE authentication and authorization services and the various authentication and authorization protocols that those services support.
The GSSAPI combines authentication and authorization under a single security concept called a mechanism. The security mechanism provides applications a choice of either Kerberos security or Privilege Attribute Certificate (PAC) authorization under DCE security.