Authenticated RPCDCE RPC and DCE security cooperate to provide authentication, authorization, and secure communications. In order to use authenticated RPC, the client must already have a security environment, such as that set up by the login facility. The server side of the application registers its name and the type of authentication service it supports. In DCE, two types of authentication service are supported - secret key authentication, which is based on Kerberos (see DCE Security and Kerberos), or no authentication. The client makes a call to indicate which authentication service, protection level, and authorization service it wants to use for RPC communications with a given server. The authentication service can be either secret key authentication, or no authentication. The protection level ranges from authentication at the beginning of an RPC session, to authenticating each message or packet, to ensuring that a packet has not been modified in transit, to encrypting all user data. In general, the more secure the protection level, the higher the price paid in terms of performance, since the security mechanisms involve encrypting and decrypting data, which take up CPU time. The authorization service chosen by the client can be either uncertified or certified. In uncertified authorization, the authorization information sent to a server consists only of the client's name. In certified authorization, the authorization information consists of the UUIDs of the client's name and groups. The certified authorization information is in the form of an Extended Privilege Attributes Certificate (EPAC), which is produced by the privilege service. In both the certified and uncertified authorization service, the authorization information is sent securely. The authentication and authorization information about the client are used by the server to determine whether the client should be granted the access to the resource that it has requested. The server knows for certain the identity of the client, and what authorization groups the client belongs to. The server can therefore compare the client's credentials against information in access control lists and determine whether a client should be given the access it is requesting.
|