Handling Access Controls at the Server

Other articles on roles have suggested implementing new forms of access control logic to support them. This is perhaps the ideal theoretical solution, but in line with the practical approach taken in this chapter. It is possible to use the access control list (ACL) logic that already exists in the majority of server operating systems for legacy systems. This requires that incoming attributes be mapped onto the ones supported by the ACLs in the target server. Mapping onto ACLs should be thought of as a bridging mechanism. The approach is much simpler for applications that have been written to use the role and affiliation attributes directly, as described later in this section.

First, however, how role and affiliation data are carried to the target server in the PAC must be identified. (Both SESAME and OSF/DCE permit an enterprise to define its own attribute types.) It is possible, as suggested earlier, for the role to be carried as a role attribute. Affiliation could sensibly be carried either as a separate group attribute or specifically as an affiliation attribute.

For the purposes of this chapter, assume that the server operating system understands user identities (UIDs) and groups that are defined locally to the operating system. Users can be members of a number of groups. Applications run under a single UID, which may have associated with it none or more groups of which the UID is a member. ACLs are associated with protected operating system objects (e.g., typically files) and have entries specifying which UIDs and groups have what kinds of access to these objects. The types of access supported are the simple traditional ones such as read, write, update, execute, append, and delete. One UID is identified in the ACL as the owner of the object protected by that ACL. This UID can modify the ACL itself and, therefore, control access to the object.

The component of the SESAME technology implemented in target servers includes the function that allows a resource controller to specify how attributes in an incoming PAC are to be mapped onto local operating system UID and group attributes. Thus, a SESAME conformant application that is started up as a result of an access request can be started under whatever UID the controller specifies should be mapped from whatever incoming PAC access control attributes that he or she chooses to identify.

Further, other incoming access control attributes can be mapped onto local group values. This enables operating system ACLs to be used for controlling access by the application to operating system objects. The application can use the role attribute directly to dictate what functions the user is allowed to perform, and the underlying operating system can dictate through its normal ACL controls the data objects on which these transactions can be performed. There are many ways of doing the mappings, but in all cases the ACL entries must be set up so that the group or UID values in the ACL entries are mapped from incoming affiliation (and optional role) attributes.

Applications that handle personal data without using RBAC control can run under a UID mapped from the incoming user’s access identity attribute, creating conditions that would have applied had the user signed on directly to the target server.

TP applications would usually be under an RBAC regime, but they work in a different way from client/server applications. Because the application is usually multithreaded, its UID is likely to be related to the application itself (or to the administrator who set it up) rather than to the user on whose behalf it is currently working, so it is not possible to use operating system access controls sensibly to control the usual users’ access rights. Therefore, TP applications must perform their own access checks, and to do this they must use a suitable application program interface (API) to extract the current user’s access attributes from the security infrastructure. A generally accepted API for doing this is the extended GSS-API, which is being adopted by X/OPEN, ISO, and the Internet Engineering Task Force.

In OSF/DCE, a different approach is taken. The security functions in the server include a distributed ACL (DACL) service that is independent of the local operating system’s ACLs and that is available for use through an API (not the GSS-API), which enables a calling application to use incoming attributes directly, without needing to know specifically how they are used. The DACL entries contain global user and group identity values that directly correspond to the incoming ones. Thus, a role must be represented directly in the PAC as one of these attribute types. Specific extensions to the DACL semantics to handle roles more effectively have been proposed, but have not yet been adopted.