OSF DCE Application Development Guide--Introduction and Style Guide

ManualsBrandsHP ManualsServerHP NonStop G-Series

OSF DCE Application Development Guide—Introduction and Style Guide

The server may of course, simply be satisﬁed that the client is authenticated and

check no further. Or the server can

3. Check that the protection level is acceptable. This too is a matter for negotiation

between the client and server applications, but it is important to begin by

considering the runtime’s mediation of the protection level request. Recall that the

client speciﬁes a speciﬁc protection level for a binding, whereas the server, when

it registers its authentication information, speciﬁes only the authentication service

it will use.

The chosen (agreed upon by the client and server) authentication service may not

support all protection levels for all protocols. Therefore, the runtime adopts the

policy of translating the client’s protection level request to the next highest

protection level actually supported by the authentication service and protocol in

use. This means that the server application will see a protection level greater than

or equal to the one requested by the client.

Most server applications will establish a policy for the minimum acceptable

protection level. In this case, if the level returned by the server application when it

calls rpc_binding_inq_auth_client() is below the standard, the server manager

fails the access request. It is perfectly possible, however, for a server to require a

lower level of protection. For example, a server may want to avoid the

considerable overhead of full data encryption and thus refuse to service requests

for this level.

4. Check that the authorization service is acceptable. Once again, this is a matter for

negotiation between the client and server applications. The server application

provides an access testing mechanism for authorization services it supports. There

are three possibilities:

• Authorization based on the client’s principal name (rpc_c_authz_name).

• Authorization based on the client’s credentials (rpc_c_authz_dce). This

involves checking the client identity’s permission set (extracted from an ACL

associated with the object the client is attempting to access) against the

required permissions for the requested operation. The client’s identity is

extracted from its credentials, contained in its binding.

• The server may permit access without authorization checking

(rpc_c_authz_none).

Name-based authorization is straightforward, but of very limited utility. In the

simplest form, the application compares the extracted name string with a set of

permitted names. However, the application is entirely responsible for maintaining

and manipulating the set of permitted names securely, which is a nontrivial task.

For example, the application must provide for some administrative way to update

the set of permitted users. Typically, this will require maintainance of a restricted

access ﬁle in some application-speciﬁc format. This is the kind of administrative

overhead that applications should be designed to avoid.

If the server application is willing to permit access by group and organization, it

can somewhat offset this difﬁculty by making a group or organization membership

check for the speciﬁed principal name. However, the basic objection remains that

an application doing name-based authorization must maintain and administer a

private security namespace (consisting of principals, groups, and organizations

3− 18 Tandem Computers Incorporated 124246