Access control in middleware consists of two functions: (1) the TSS making an access decision and (2) enforcing it. See Figure 7.4. The enforcement part is fairly easy since the ORB gives the TSS an opportunity to intercept an invocation and enforce the poli- cies. The hard part here is the access control decision (authorization). Authorizations are challenging because they have to be quick to reduce security-related overhead, but depending on the authorization policies and the number of objects in the application system, the decision process can be quite complex.
First, we need to figure out what policies should govern authorization decisions for the request in question. Since the policies are needed for message protection, auditing, and other security functionalities, this task is not as trivial as it might sound. The rea- son is that objects are often organized into groups, each protected by a distinct policy, to achieve scalability in middleware object-based systems. The groups are then orga- nized in complex relations so that large numbers of objects with similar security requirements can be governed by a few base policies. Policies for objects with peculiar
requirements could be obtained through some composition of the policies according to the group relations. An example of such relations is the use of hierarchies, where each node is associated with a policy and leaves in the hierarchy are objects “hanging off” the nodes. This object hierarchy approach allows you to impose base policies near the hierarchy root and to fine-tune the protection of some objects located down the tree. A simple example illustrating object hierarchies is shown in Figure 7.5.
Besides the difficulty of determining policies due to the scale, as you remember from the section on the object paradigm, some objects may have many names and some may be anonymous, making it difficult to identify what group(s) they belong to. Addition- ally, object encapsulation and method semantic complexity make objects and their methods opaque to the outside world (at least to the poor security administrators), which then means that an extra level of indirection is required to compute those attrib- utes of objects and methods that can be used for calculating applicable policies. Every middleware security technology described in this chapter categorizes methods into related groups in some way. We will discuss the techniques for determining object group membership and method categorization for each technology.
Then, various policies governing access to the object’s method might have to be composed into one “ultimate” policy that is evaluated to come up with a final access decision. The composition may not be trivial since the policies could contradict each other, with one policy granting and the other denying access. Consequently a “metapolicy”, which is a policy about composing policies, is required to resolve the conflicts. How a resulting policy is computed depends on the semantics of the relation and varies from technology to technology. For some, more specific policies take higher priority. For others, all policies are compiled into a list and those at the top of the list take precedence over later ones. There are other strategies as well.
Figure 7.4 Access control is a combination of decision and enforcement functions.
Middleware Target Security Service
Decision Request Access Request Decision Target Application Access Request Enforcement Function Decision Function
Figure 7.5 Sample hierarchy of object groups.
Most practical security policies consist of statements that either grant or deny access. The statements usually contain references to one or more of the following:
■■ Subject attributessuch as groups, identity, roles, and clearance, age, location
■■ Resource attributessuch as name, the owner identity, security label, location
■■ Operationon the resource
■■ Environmental informationsuch as time of day, day of week, global state (for example, emergency, under terrorist attack)
■■ History information, such as how many times the principal has accessed the resource before
■■ Request information, such as the level of the channel protection through which the request came and through which the response will be sent back
■■ Obligationsthat specify additional conditions to be satisfied before access is granted, such as an agreement to be signed by the end user, auditing the trans- action, or availability of funds.
Policy A Policy B Policy C Group B Group C Group D Group A Object F Object G Object J Object H Policy D 168 Chapter 7
These references need to be resolved before their values can be used in policy eval- uation. The CSS and TSS gather the values in two ways:
Push model. In this mechanism, information is “pushed” to the TSS although it
was not requested. For instance, the CSS may send an access request including the subject attributes as well as the operation name to the TSS.
Pull model. Not all information can be obtained by the CSS beforehand, due to,
for example, the cost associated with retrieving it, the inability to do so, or even the low trust that the TSS has in client-provided information. In this situation, a pull model becomes indispensable. The TSS will need to request this security information to have it “pulled” from a security policy server.
Some information, such as environmental data, is better to “pull.” At the same time, one can find a combination of push and pull models for a principal or resource attrib- utes. A good example of mixing the push and pull models is the Dynamic Attribute Service (DAS) object in the Resource Access Decision (RAD) architecture (Hartman et al 2001). With RAD, before an access request is dispatched to the policy engines, all principal attributes pushed with the access request are sent to a DAS along with the resource name. The DAS could “pull” additional attributes, which are specific to the access request in question, and add them to the “pushed” ones. It could even replace “pushed” attributes with “pulled” or even drop some, depending on the governing logic.
Since access control plays a key role in both middleware and Web Services security, we devote a significant amount of material to the subject in this chapter and several others.