Assuming either that authentication has taken place and succeeded, or that no authentication has taken place, some server manager operation will then be invoked by the RPC runtime to handle an RPC call. This operation should, as its first duty, make an authorization decision.
A server manager operation calls rpc_binding_inq_auth_client( ) to extract any authentication information for the calling client and then makes a series of decisions. The usual model is that the server establishes a set of access criteria and rejects the call if all criteria are not met. This is implemented as a series of tests, the server rejecting the call at the first failed test. The possible tests are as follows:
1. Does the client binding provide any authentication information? For this purpose, the application should check status after the call to rpc_binding_inq_auth_client( ). If no authentication information is provided (the status returned is rpc_s_binding_has_no_auth), the authorization function must decide whether this is acceptable. The authorization function may make its decision based on the unauthenticated ACL type, as noted later in this topic.
If authentication information is provided, then the application should go on to ask:
2. Is the authentication service acceptable to the server? The application checks the authn_svc parameter. Currently this check is redundant, since the only authentication service available is DCE secret key (the authn_svc returned is rpc_c_authn_dce_secret).
Note: There is considerable asymmetry in the use of the authn_svc values on the client call to rpc_binding_set_auth_info( ) and the server call to rpc_binding_inq_auth_client( ). If the client specifies rpc_c_authn_none, the server sees a status of rpc_s_binding_has_no_auth, and no meaningful value is returned for the authn_svc parameter. Furthermore, given that the default authentication service is DCE secret key, if the client specifies rpc_c_authn_default, the server returns rpc_c_authn_dce_secret from authn_svc. In other words, while the client can specify three different values for authn_svc, the server can return only one.
The server may of course, simply be satisfied 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 specifies a specific protection level for a binding, whereas the server, when it registers its authentication information, specifies 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 file in some application-specific 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 difficulty by making a group or organization membership check for the specified 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 associated with access privileges). Since the credential-based (ACL) method is designed to provide a general solution to this problem, it is much to be preferred. ACL based access checking is described in the following topics.
If the authorization service requested is acceptable, the server application makes the appropriate access tests as described in step 6.
5. Check that the server principal name specified by the client is acceptable. This check is useful for a server that is running with more than one principal identity. The server may only want to allow the operation under a specific principal identity. If the server is running with only one principal identity, this check is redundant.
6. Extract the client privileges and perform the appropriate access testing. The form of the client privileges depends on the authorization service. The application needs to extract the privileges in the correct format and pass them to the appropriate access tests.
More: