GB2431747A

GB2431747A - Identification of conflicts between policies for methods in object orientated environment

Info

Publication number: GB2431747A
Application number: GB0522098A
Authority: GB
Inventors: Antonio Lain; Patrick Goldsack
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2005-10-29
Filing date: 2005-10-29
Publication date: 2007-05-02
Also published as: GB0522098D0; US20070101312A1; US7926028B2

Abstract

A computer process for determining conflicts in policies for methods invoked by an object comprises obtaining and comparing the associated polices for each method in a method grouping to identify any conflicts. A policy may be an access control system. In use, methods and associated policies are stored in a look up table system. A policy may be associated with a method using a method signature determined as a function of the method name and method data. Where no policy exists for a method an entry is created in the look up table. If only one policy is, or if only compatible policies are, associated with the method then a no-conflict state occurs. If incompatible policies are associated with a policy then a conflict state is identified and a conflict resolution policy is preferably implemented.

Description

A COMPUTER IMPLEMENTED PROCESS FOR IDENTIFYiNG CONFLICTS

BETWEEN POLICIES

FIELD OF THE INVENTION

[0001] The invention relates to a computer implemented process for identifying conflicts between policies.

BACKGROUND OF THE INVENTION

[0002] Object oriented programming, in which an object defines both data and the operations to be performed on the data, is a field that is well known to the skilled reader. In object oriented programming a class is defined providing a template of attributes defining data and methods defining operations and an object corresponding to the template is created by instantiating the class as shown in Fig. 1 to provide an object 100 having a description including one or more attributes 102 and one or more methods 104, the methods further being identified by associated arguments.

100031 The methods can be defined within the object or, as shown in Fig. 2 may be invoked from another object. For example an Object 1, reference numeral 200 may call Method 1, reference numeral 202 from Object 2, reference numeral 204.

100041 In a remote method invocation (RMI) system the Method 1 may then be invoked from another location. For example in programming languages such as Java a group of methods is described in an interface. An interface comprises a statically defined grouping of methods which can be declared in the object when it is instantiated or can be defined in the class. At compile time all of the methods associated with the object by the interfaces are then discovered by known techniques such as introspection whereby the methods associated with the interfaces are collated from inspection of the interfaces. Then, in run time, and referring once again to Fig. 2, therefore, Object 2 invokes Method 1 from Interface 1, reference numeral 206.

[00051 It is convenient to associate a common security policy 208 to all the methods contained in an interface 206. This is particularly useful when, in languages like Java, methods that are remotely accessible for example by using RMI and therefore particularly vulnerable are marked by declaring them as part of a "remote" interface. The policy may be implemented for example as an access control system in the form of an access control list (ACL) determining, for security purpose, who may invoke the method. The ACL associated with the interface is specified within the object itself in an interface/ACL pair, the ACL being associated when the object is created and selected according to any appropriate approach.

For example it can be part of the description creating the object or can be retrieved from an ACL database as appropriate. Various languages are provided describing access control policies and associating policies to interfaces, such as DTEL++ which is described in "Scaleable access control for distributed object systems" of Steme et al, proceedings of the Eighth Usenix Security Symposium Washington DC USA August 23 to 26, 1999 which is incorporated herein by reference.

BRIEF SUMMARY OF THE INVENTION

[0006] A computer implemented process for identifying conflicts between policies for a method invocable by an object is described, in which the method is a member of at least one statically defined method grouping having a corresponding policy. The process comprises, for each method grouping, obtaining each method which is a member of the method grouping, associating therewith the corresponding method grouping policy, and comparing policies associated with methods which are members of two or more method groupings to identify conflicts.

BRIEF DESCRIPTION OF THE DRAWiNGS

10007] Fig. 1 is a schematic diagram illustrating an object; method.

100081 Fig. 2 is a schematic diagram illustrating method indication by an object; 100091 Fig. 3 is a schematic diagram showing an exemplary object interaction; 1000101 Fig. 4 is a schematic diagram showing method invocation by an object according to the method described herein; [00011J Fig. 5 is a flow diagram showing a process for identifying conflicts in method invocation; 1000121 Fig. 6 is a flow diagram showing in more detail a process of identifying conflicts during method invocation; 1000131 Fig. 7 is a schematic diagram showing a table of policies associated with method identifiers; and 1000141 Fig. 8 is a schematic diagram showing a computer system upon which the method described herein can be implemented.

DETAILED DESCRIPTION OF THE INVENTION

100015] In overview the method described herein can be understood with reference to Fig. 3 to 5. Referring firstly to Fig. 3 an interaction between two exemplary objects is shown where object I is named "stocktake" and object 2 is named "inventory". The stocktake object 300, includes as an attribute 302, STOCK and as a method 304, CALCULATE. The inventory Object 306 includes as an attribute 308 ITEM 1 to ITEM N and as methods GET ITEMS (1), GET ITEMS (abc) 310. For the purposes of illustration it will be noted that two methods with the common name GET ITEMS are included in the object. This is because in some implementations it is possible to "overload" a method name such that two different methods may have the same name, for example. In such implementations the methods are distinguished by an associated argument which may be a string or integer. For example in the case of the overloaded method name GET ITEMS, GET ITEMS (I) has an integer argument which could be distinguished from other integer arguments or any string argument whereas GET ITEMS (abc) has a string argument distinguishable from other string arguments or any integer argument. In addition each object lists its interface/ACL pairs. For example the inventory object 306 may list, at 314, the interface/ACL pairs that it implements, for example an interface A may have an associated ACLA, interface B has ACLB and interface C has ACLC. Accordingly in order for the stocktake Object to perform the operation CALCULATE STOCK it needs to call, say, the method GET ITEMS (1) as shown by arrow 312 from the inventory Object which then invokes the method applying the policy corresponding to the appropriate interface according to the interface/ACL pair as discussed in more detail below. The inventory Object then returns the information to the stocktake object which can then populate the attribute STOCK with the returned data. In the present example it is assumed that each ACL or policy associated with the relevant interface dictates that the method is only useable by a pre-determined group for example executives, managers, warehouse operatives and so forth.

[00016J Fig. 4 shows conceptually one manner in which the relationship between objects and multiple interfaces can be expressed. it will be seen that protection or resolution of conflicts between policies is required in some cases, for example, when a method is called from multiple interfaces by an object itself where each interface may have a different policy associated with it and its methods and may itself inherit methods from one or more "parent" interfaces. For example the stock-take object 400 may call method 1 402, for example the GET ITEMS (1) method from the inventory object 404 which then invokes the method. It can be seen that a complex hierarchical interface structure may be encountered including interfaces A, B, C, reference numerals 412, 406, 408, directly invocable by the inventory object. In addition one or more of the directly invocable interfaces may themselves inherit the method from further interfaces. For example interface B 406 may inherit from parent interface A, reference numeral 412..

[00017] In the present example, where interface B 406 inherits method GET ITEMS (1) 402 from interface A 412 as shown by arrows Y and Z, and interface C also describes GET ITEMS (1) conflicts can arise where different policies are associated with each of the interfaces A, B or C. Because the ACL's are typically associated with the object as it is created, whereas the methods and interfaces it implements are determined by the class, it can be seen therefore that conflicting policies for the same method can arise if the ACLs are inconsistent. For example the inventory object may specify by its interface ACL packages 314 in Fig. 3 that interface A has a policy ACLA that only executives may perform the GET ITEMS method whereas interface B has a policy ACLB that only managers can perform the GET ITEMS method. The process described herein deals with the added complexity resulting from describing groups of methods via interfaces and in particular ensures that conflicting policies are not introduced by using different interfaces that have, or inherit, common methods, by detecting such conflicts. In particular because the specific interface used to invoke the method by the remote client is not known or at least not necessarily trusted, the problems that would otherwise arise with correct enforcement of conflicting policies do not occur and the actual method invoked can be relied on instead.

[000181 The specific examples described herein are expressed in terms of the Java language although it will be appreciated that the steps involved can be implemented in any appropriate manner in relation to any appropriate language where multiple inheritance is supported and a one-to-one mapping to actual methods is not required such that a method can be described in multiple interfaces or none, as in all of these cases it is vital to ensure that a consistent security policy is available when different policies are associated to different interfaces.

1000191 Conflict detection can be understood, in overview, referring to Fig. 5. At step 500 all interfaces associated with the target object together with their corresponding policies are obtained and at step 502, all of the methods implemented by each of the interfaces andlor any of its super-interfaces are discovered. At step 504 it can be established whether more than one policy is associated with the same method by checking against a look-up table which can be dynamically populated during execution of the process as discussed in more detail below.

In addition appropriate steps can be taken to allow differentiation between methods that have common names but differ in static parameter types, i.e. arguments, again as described in more detail below.

[00020] As a result conflicting policies are not enforced for object method invocation policies as specified at the level of interfaces. This is because the interface selected by the client for the invocation is irrelevant and security decisions in the server are based on the actual method implemented by the class of which the object is an instance and not on the interface.

1000211 It will be appreciated that the processes described as follows can be implemented at any appropriate time for example during development and either statically or dynamically as appropriate. For example when it is desired tO deploy a new object appropriate checks can be carried out to ensure that there are no conflicts arising from multiple interfaces associated with the object and this can be carried out off- line or on-line as an object is created or as a method is called.

[00022J The process described herein can be understood in more detail with reference to Fig. 6 and the following exemplary code: Listing I II Detects whether there is a conflict in the proposed set of access control II policies applied to groups of methods described herein by interfaces conflictDetection(Object In, List_ of {Interface intf, ACL acl} req,

HashTable results) {

for every entry X in req { checklmplementslntf(In, X.intf); Set M = findMethods(X.intf, new SetO); for every entry meth in M { methName = hashName (meth); old = results.get(methName); if ((old EQUALS null) OR (X.acl EQUALS old)) { results.set(methName, X.acl); } else { RAISE "conflicted detected" exception; 1000231 In particular, at step 600 the inputs to the process are a list of interface/ACL pairs and an object that it is desired to protect with those policies. The interface/ACL pairs are, for example, defined in the programmatic description setting out how to create the object as an instance of a class, or may be read from a file or obtained in any appropriate manner. At step 602 in the "checklmplementslntf" step a check is carried out to ensure that, for every interface/ACL pair associated with a target object, the object implements that interface for

example as follows:

Listing 2 II Ensure that the object implements the interface we want to protect.

checklmplementslntf(Object in, Interface intO { if in is not an instance of intf { RAISE "conflict detected: incompatible interface"; 1000241 At step 603 first interface/ACL pair, is selected and at step 604 all methods implemented by the interface (or any of its parent interfaces) are found for example, by introspecting the interfaces at run-time by using Java reflection mechanisms -which are well known to the skilled reader as a method of traversing the hierarchical structure shown in Fig. 4 to obtain information about the classes/methods/interface supported by a particular object such that detailed description is not requested here. This can be achieved for example as follows: Listing 3 II recursively finds all the methods implemented by an interface or any I/inherited by its superinterfaces Set findMethods(Interface intf, Set results) for all methods M in intf { results.add(M); for all superinterfaces superlntf of intf{ results = findMethods(superintf, results); return results 1000251 In step 606, a method signature (methName) is computed as a function of the method name itself e.g. GET ITEMS and the arguments attached to the method eg (1) or (abc). The combination step can be carried out by any appropriate operator, for example the method name and argument types can be concatenated to return a unique string as the hash name (hashName) value using any appropriate hash function as will be well known to the skilled reader: Listing 4 II return a unique string for that method name and all its arguments II static types.

String hashName(Method meth) { Return HASH(meth.name, "-", ClassOf(meth.arg I), "-", ClassOf (meth.arg2) ....) 1000261 Ensuring that a unique string is obtained in each case avoids problems that could otherwise arise with overloaded methods where methods with similar or the same names but different arguments can be added for example to a sub-class. Instead conflict detection is carried out in relation to a "signature" associated with the method that does not include interface information but contains a description of argument types so that we can allow duplicated method names. It will be appreciated that this step is only required in languages where the possibility of overloading is allowed.

[000271 At step 608 a datastructure such as the table shown in Fig. 7 is populated with entries comprising each of the discovered methods, identified by method signature, together with the ACL associated with the interface in relation to which they were discovered. For example where a single method having method signature MS 1 is discovered for interface/ACL pair X/ACLX, then ACLX is entered against MS 1 in the table.

[00028] In step 609 for each of the remaining interface/ACL pairs steps 604 to 608 are repeated to obtain all of the method signatures associated with each respective interface. For each iteration the method signatures returned are checked against the existing table and the table is dynamically updated during the process. In particular, at step 610 a check is carried out to see whether an ACL already exists against a method signature. For example in the case of Fig. 7 if a method signature discovered for interface Z/ACLZ is MS2 it will be seen that no ACL is entered in the table of Fig. 7 against it. Accordingly at step 612 the table is populated for M52 and with the new ACLZ and at step 614 a "no conflict" output is provided against that method. 1f however, an ACL already exists against the method signature then at step 616 a check is carried out to establish whether it is a compatible ACL with the new ACL. For example, MSI is discovered but ACLZ is compatible with ACLX at step 616 then an output of"no conflict" is provided at 614.

1000291 If, however, the ACL in the table is not compatible with the new derived ACL then at step 618 an output "conflict detected" is provided. At this stage the process can be stopped and the conflict resolved manually. Alternatively, at step 620 the conflict can be resolved automatically according to any appropriate policy. For example the most specific policy amongst the ACL's can be adopted or the first policy found can be adopted or indeed any other approach can be pursued as appropriate. It will be noted that the table shown in Fig. 7 can be of any appropriate type such as a look-up table and created in any appropriate manner. For example if the system is tested in a single run then the table can be populated dynamically as the process proceeds. Alternatively if the system is tested incrementally then the table can be maintained and updated through each incremental run.

1000301 Reverting to the example discussed above with reference to Figs. 3 and 4, application of the process described herein can be further understood. Assuming that three interfaces A, B and C can be expressed: Listing 5 public interface A { getltems (1); public interface B extends A { II also includes method get item from A getltems (abc); public interface C { getltems (1); 1000311 A class can then be created that implements interfaces A, B and C: Listing 6 public class Inventory implements B, C { public Inventory 0 { public getltems (1) { public getltems (abc) { 1000321 An object inventory is now created as an instance of the class inventory which can be expressed: Listing 7 Inventory inventory = new Inventory0; [000331 If, for the previous object instance "inventory", ACL B is associated with interface B and ACL C is associated with interface C such that only managers satisfy ACL B and only executives satisfy ACL C it will be seen that conflict will appear when evaluating the ACL associated with the method "getltems (1)". Since the method is defined in both interface B (via interface A) and also in interface C, both ACL B and ACL C are relevant but are inconsistent with one another.

[00034] Then applying the process described herein, the input to the flow shown in Fig. 6 the object "inventory", the interface/ACL pairs interface B/ACL B, interface C/ACL C are derived and, inter alia, the methods "getltems (1)" would be returned as implemented by the interfaces. The method signature would then be computed and from the table populated with the methodlACL pairs the conflict would be detected and then resolved in any appropriate manner.

1000351 It will be noted that the method getltems(abc) results in the hash value Hash["getltems_String"], different from the previous one, and therefore, no conflicts are found for that method.

1000361 It will be appreciated that the process described herein can be implemented in any appropriate manner and in any appropriate language. Furthermore the platform on which the process is implemented can be selected as required as will be apparent to the skilled reader.

For example the process can be implemented in the Smart Frog distributed computing environment as described at http://www.smartfrog.org.

1000371 For example a plurality of remote entities 800, 802, 804 may implement the process including a data processors 800A, 802A, 804A, a memory 800B, 802B, 804B and an inputloutput interface for sending and receiving communications between the entities 800C, 802C, 804C. Each of the entities may process method calls by objects calling those methods internally to themselves or from other entities as appropriate and dynamically or statically as required to arrive at the process described herein. For example each of the entities may comprise ajava virtual machine (JVM) residing on one or more common platforms.

1000381 As a result of the approaches described herein, conflicts between policies can be avoided whilst still making use of interfaces. Using interfaces to specify policy has the benefit that in statically typed languages, like Java checks at compile time ensure that extra methods are not added unintentionally and the expected abstraction provided by an interface remains unchanged. Furthermore, this does not limit flexibility in choosing the right granularity of policy since many interfaces can be provided describing the same methods, policies being associated with the interfaces in different objects or implementations of the interface, without conflict arising.

1000391 It will further be appreciated that the approaches described herein can be implemented in the case of any multiple interface configurations or other statically defined multiple groupings of methods where a policy conflict may arise and in relation to any language, remote method invocation system and computer system as appropriate. The specific form and nomenclature applied to objects, methods and interfaces can be adopted as appropriate and it will be recognized that the terms used herein can be replaced by appropriate equivalent terms where required in implementation of other computer languages.

Claims

Claims 1. A computer implemented process for identifying conflicts

between policies for a method invocable by an object, in which the method is a member of at least one statically defined method grouping having a corresponding policy, the process comprising, for each method grouping, obtaining each method which is a member of the method grouping, associating therewith the corresponding method grouping policy, and comparing policies associated with methods which are members of two or more method groupings to identify conflicts.

2. A process as claimed in claim 1 in which the policy comprises an access control system.

3. A process as claimed in claim 1 which the method grouping comprises one or more interfaces.

4. A process as claimed in claim 1 in which methods and associated policies are stored as associated entries in a look-up data structure.

5. A process as claimed in claim 4 comprising populating a look-up data structure policy entry for an associated method with an associated policy if no associated policy entry exists.

6. A process as claimed in claim 1 in which, if only one policy is associated with the method, a no-conflict state is identified.

7. A process as claimed in claim I in which if only compatible policies are associated with the method then a no-conflict state is identified.

8. A process as claimed in claim I in which if incompatible policies are associated with the method then a conflict state is identified.

9. A process as claimed in claim 8 further comprising implementing a conflict resolution policy.

10. A process as claimed in 1 further comprising computing a method signature as a function of a method name and associated method data and associating the policy with the method signature.

11. A computer readable medium containing instructions arranged to operate a processor to implement the process of claim I. 12. An apparatus for identifying conflicts between policies for a method invocable by an object in which the method is a member of at least one statically defined method grouping having a corresponding policy, comprising a processor arranged to obtain, for each method grouping, each method which is a member of the method grouping, associating therewith the corresponding method grouping policy and comparing policies associated with methods which are members of two or more method groupings to identify conflicts.

13. An apparatus for identifying conflicts between policies, the apparatus including a processor configured to operate under instructions contained in a computer readable medium to implement the process of claim 1.