Patent Publication Number: US-2004054696-A1

Title: System and method for using proxies

Description:
FIELD OF THE INVENTION  
       [0001] The present invention relates to computer methods that intercept access requests or the like, and more particularly relates to a system and method for using dynamic proxies.  
       BACKGROUND OF THE INVENTION  
       [0002] An object of the Java Version 2.0 Enterprise Edition™ (J2EE™) platform, and of Java itself, is the compartmentalization of separate sets of functionality in distinct components. While J2EE applications can be developed from the ground up, it is often the case that these applications are assembled by a solution provider from a number of commercially available components. Even where a J2EE application is developed from the ground up by one solution provider, different components are typically developed by different programmers, thus presenting certain challenges when combining components from different sources.  
       [0003] Particular challenges of combining components are found in enterprise applications, which are typically mission-critical. The qualities of security, logging and reliability are, therefore, important considerations in the development of J2EE applications. The implementation of the additional functionality to provide these qualities, however, often requires additional code to be introduced into a number of components.  
       [0004] Security is an important issue in most J2EE applications in that these applications provide access to sensitive data and functionality contained in the back end by components known as Enterprise Java Beans™, or EJBs™. The current Specifications for EJB Version 2.0, Final Release, by Linda G. DeMichiel, L. Unit Yalcinalp and Sanjeev Krishnan of Sun Microsystems, Inc., Santa Clara, Calif., dated Aug. 14, 2001, (“EJB Specification”) can be found on Sun&#39;s Website at http://java.sun.com/j2ee/docs.html and are incorporated herein by reference. EJBs are comprised of a set of interfaces and classes. While the EJB specification provides a role-based model for providing security to a J2EE application, other types of security, such as entity-based security, are not addressed and are typically provided by inserting additional code into each EJB for which other types of security are required. The process of inserting security code into a number of EJBs manually is error-prone as it is performed by either the programmer responsible for programming the main functionality of an EJB who may not understand the context of the security code, or a programmer responsible solely for security who may not understand the main functionality being provided by the EJB.  
       [0005] Logging is another important aspect of enterprise applications in that it allows the function of the application to be checked to ensure that it is behaving as desired. Further, logging enables the review of accesses made to various resources by various individuals for purposes of determining if individuals were attempting to access resources they are unauthorized to access, or were attempting to circumvent security or damage the application and/or the data accessible to the application. The J2EE Specification does not inherently provide a tool that performs logging. Logging can be performed by inserting custom code into a number of EJBs, but there are advantages in performing logging in the environment receiving the request.  
       [0006] In order for an enterprise application to be made more reliable, the number of code issues affecting its reliability must be reduced. Quality assurance testing is typically the method by which most code issues are discovered. The process of quality assurance testing involves receiving a set of code, designing a set of tests to be performed on the set of code based on the functionality to be provided by the set of code and the environment in which the code will be run, executing the tests and recording a set of results including a number of test failures, providing a list of these failures to the programmers who developed the code set so that fixes can be made to the code, and repeating the previous steps by retesting the fixed code with the same set of tests previously performed on the code until a desired level of reliability of the code is achieved. The process of running each of the tests in the set manually is repetitive, long and increases the probability for manual error.  
       SUMMARY OF THE INVENTION  
       [0007] In a first aspect of the invention, there is provided a method of providing entity-based security in a computer system, comprising the steps of: intercepting, using a proxy, a request received from a client on behalf of a user; determining via the proxy whether the request is authorized based on a set of access control rules that are respective to an entity associated with the request; performing the request via the proxy if the request is authorized; and, rejecting the request via the proxy if the request is not authorized.  
       [0008] In a particular implementation of the first aspect, the proxy performs the determining step.  
       [0009] In a particular implementation of the first aspect, the determining step comprises the steps of: deriving a security characteristic associated with said request; deriving an access right from said security characteristic; comparing said access right with said access control rules; providing authorization if said right is validated by one of said access control rules; denying authorization if said right is not validated by one of said access control rules; and, returning said approval or denial thereof back to said proxy. The security characteristic deriving step can be performed by an access manager separate from said proxy. The security characteristic can be a user-id and one of the commands of creating, removing, updating, deleting and viewing. The access right deriving step, the comparing step, the approval step and the denial step can be performed by the policy manager.  
       [0010] In a particular implementation of the first aspect, the request is directed to a service locator in a Java container. The service locator can use the java.lang.reflect.Proxy class to generate the component proxy.  
       [0011] In a second aspect of the invention, there is provided a system for entity-based security comprising: a server having a central processing unit (CPU), a data storage device for exchanging non-volatile data with said CPU, random access memory (RAM) for exchanging volatile data with said CPU, and an input device for receiving data for the CPU and output device for presenting outputted data from the CPU; the CPU operable to receive, via the input device, a request to access one of a plurality of server objects stored in the data storage device, each of the server objects representing an entity; the CPU further operable to provide the request to a proxy for authorizing or rejecting the request based on a set of access control rules that are respective to each of the entities; and, the CPU further operable to present the authorization or rejection to the output device.  
       [0012] In a particular implementation of the second aspect, the input device is a keyboard connected to the server and the output device is a monitor connected to the server.  
       [0013] In a particular implementation of the second aspect, the input device and the output device are combined in a network interface card (NIC) that is connectable to a client machine.  
       [0014] In a particular implementation of the second aspect, the CPU is executing Java Enterprise Edition. The request can be directed to a service locator in a Java container and the service locator uses the java.lang.reflect.Proxy class to generate the component proxy.  
       [0015] In a particular implementation of the second aspect, a set of roles are defined for each of the entities, and the access control rules reflect access rights corresponding to each of the roles. The roles include an administrator, a viewer and an owner.  
       [0016] In a particular implementation of the second aspect, the access rules reflect a right to perform at least one of creating, removing, updating, deleting and viewing the one server object.  
       [0017] In a particular implementation of the second aspect, the set of access control rules are codified in a set of Java classes.  
       [0018] In a particular implementation of the second aspect, the entity is represented as an entity bean.  
       [0019] In a particular implementation of the second aspect, the request is for a method associated with the server object.  
       [0020] In a particular implementation of the second aspect, the request is for an attribute associated with the server object.  
       [0021] In a third aspect of the invention, there is provided a system for providing entity-based security, comprising: a server providing a set of application functionality providing access to a number of sets of data representing a number of objects; a proxy executing on the server that is operable to determine whether an access request that is directed at one of the number of sets of data corresponding to one of the number of objects is authorized based on a set of access control rules. a database storing a set of user access rights for the number of sets of data. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0022] The present invention will now be described, by way of example only, with reference to certain embodiments of the invention and the attached Figures, in which:  
     [0023]FIG. 1 shows a system for implementing declarative entity-based security comprising a number of client machines connecting to a server in accordance with an embodiment of the invention;  
     [0024]FIG. 2 shows a schematic representation of various software and hardware components implemented on the system shown in FIG. 1;  
     [0025]FIG. 3 shows a flow chart of a method of providing entity-based security in accordance with an embodiment of the invention;  
     [0026]FIG. 4 shows a flow chart of a method of authorizing an action providing entity-based security in accordance with an embodiment of the invention;  
     [0027]FIG. 5 is an exemplary organizational chart demonstrating a number of users of a system upon which entity-based security can be enforced in accordance with the invention;  
     [0028]FIG. 6 is a table of salaries for each employee in FIG. 5; and  
     [0029]FIG. 7 is a table of access rights to the Employee Record of each employee in FIG. 5. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
     [0030] A system in accordance with an embodiment of the invention is generally shown at  20  in FIG. 1. System  20  is comprised of a server  24  and a number of client machines  28  connected to server  24  via a communication medium  32 . Server  24  is any server known in the art, such as the Sun Enterprise  10440  Server, sold by Sun Microsystems of Palo Alto, Calif., and generally includes a central processing unit, random access memory, data storage means, and a computer network interface to allow server  24  to communicate over communication medium  32 . In an embodiment of the invention, server  24  is generally operable to function as a J2EE-based network computing server.  
     [0031] Client machine  28  is any computing device known in the art, (such as personal computers, network thin client machines, mobile phones, personal digital assistants, etc.) that have a basic set of hardware resources, such as a central processing unit, random access memory, input/output functionality so that it is generally operable to act as a client machine to server  24 . Communication medium  32  can be any suitable network, such as the Internet or the like. In a particular embodiment, communication medium  32  is the Internet.  
     [0032]FIG. 2 shows a number of software and hardware components implemented on the system shown in FIG. 1. Thus, as shown in FIG. 2, client machine  28  comprises a Web browser  36  that enables interaction with a series of hypertext markup language (HTML) pages  40 .  
     [0033] As shown in FIG. 2, server  24  comprises a Web container  44  and an EJB container  48 . As more particularly defined in the EJB Specification, Web container  44  and EJB container  48  are collections of components and objects that provide predetermined functionality for server  24 . Both Web container  44  and EJB container  48  can be executed in a single Java Virtual Machine (JVM) or can be segregated into separate JVMs, on separate physical machines, or can individually be distributed across more than one machine.  
     [0034] In a particular embodiment, Web container  44  hosts a one or more Java servlets  52  and/or Java Server Pages (JSPs) (not shown). In the present embodiment, it is assumed that web container  44  only hosts a single servlet  52 , but typically container  52  hosts a plurality of servlets and/or JSPs. Servlet  52  executing in Web container  44  is an application that extends the functionality of a Web server (also not shown), enabling access to data in EJB container  48  via browser  36 .  
     [0035] Web container  44  is also comprised of a service locator component  56 , an EJB proxy  60 , an access control manager  64 , a set of Java class-based access rules  68  and a security deployment descriptor file  72 .  
     [0036] Service locator  56  is analogous to a DNS lookup for Internet addresses in that service locator  56  allows the use of user-friendly aliases for home interfaces and component interfaces that are available for access on system  20 . Upon receipt of a request for a home interface or a component interface using such a user-friendly alias, service locator  56  looks up the alias in a table and determines the identity of the interface respective to the user-friendly alias.  
     [0037] EJB proxy  60  is dynamically generated using any suitable means to generate a proxy, such as the java.lang.reflect.Proxy class. EJB proxy  60  is generated in response to a request to service locator  56  for a home interface or a component interface using the user-friendly alias for that component. In particular, when servlet  52  requests a home interface from service locator  56  (such as home interface  76  in FIG. 2), an EJB proxy  60  is dynamically generated to provide a transparent supra-interface for servlet  52 , through which servlet  52  can access home interface  76 . In this fashion, direct access to home interface  76  is not allowed and EJB proxy  60  is able to control all access thereto. Service locator  56  thus wraps home interface  76  in EJB proxy  60 , providing transparent access to home interface  76  to servlet  52  via EJB proxy  60 . An additional EJB proxy  60  can be generated and likewise used to provide transparent access to other interfaces, such as component interface  84 .  
     [0038] The primary task of access control manager  64  is to authorize or reject calls or access requests made on a home interface  76  (via its respective EJB proxy  60 ) and/or a component interface  84  (via its respective EJB proxy  60 ), the details of which will be discussed in greater detail below. (As used herein, the term “call” has substantially the same meaning as the term “access request”, and the terms are used substantially interchangeably according to the context in which they are used.) In the present embodiment, access control manager  64  is a component that is separate from EJB proxy  60  (or EJB proxies  60 ), but in other embodiments of the invention it is to be understood that the functionality provided by access control manager  64  can be incorporated directly into EJB proxy  60 .  
     [0039] As previously mentioned, Web container  44  contains a home interface  76 , which is an interface for a container-provided home proxy  80 . Web container  44  also contains a component interface  84 , which is an interface for a container-provided bean proxy  88 . Container-provided home proxy  80  and container-provided bean proxy  88  provide functionality locally in Web container  44  to access an entity bean  96  in EJB container  48 . (Other container-provided home proxies and container-provided bean proxies can be included in container  44 , as desired.)  
     [0040] Security deployment descriptor  72  is an XML file similar to the standard deployment descriptor (not shown) associated with container  44 , in that each one contains a set of rules for controlling access to a set of EJBs in EJB container  48  and, accordingly, any data contained in entity bean  96 . However, while container  44 &#39;s standard deployment descriptor provides, among other things, a set of access control rules that can allow for role-based security, container  44 &#39;s standard deployment descriptor does not allow for the entity-based security that is in part provided by security deployment descriptor  72 .  
     [0041] Security deployment descriptor  72 , thus, allows for the declarative specification of a set of access control rules that are at least partially entity-based for entity bean  96  (or a plurality thereof) contained in EJB container  48 . Entity-based security is achieved by a set of tags similar to those employed to provide role-based security capabilities to the standard deployment descriptor of Web container  44 .  
     [0042] In the present embodiment, the access control rules of security deployment descriptor  72  are positively declared and are selected from a combination of entity-based and role-based requirements. That is, the authorization criteria to be met are stated in terms of the criteria for authorized groups. For example, where an entity bean represents an employee&#39;s information for an employee, and where only an employee&#39;s manager can modify the employee&#39;s information, the access control rule can be stated as “can access the entity bean with the role of administrator”. For example, roles can include “owner”, “administrator” and “viewer” where an “owner” can create, remove, update, delete and view any information of an entity, an “administrator” can update and view the information of an entity and a “viewer” can only view the information of an entity. The roles, however, can be defined as required and can have different access rights for different entities. Further, users can be assigned different roles for different entities.  
     [0043] In other embodiments, it will now be apparent to those of skill in the art that a number of different means can be employed to declare the access control rules, other than through a security deployment descriptor  72 . Further, while security deployment descriptor  72  in the embodiment is an XML file, it is understood by those of skill in the art that the same functionality can be provided by other means, including files written in other mark-up languages, objects capturing the access control rules as attributes and a set of one or more database tables.  
     [0044] Upon execution of Web container  44 , a set of supplementary access control rules  68  are generated from the access control rules codified in security deployment descriptor  72  and are encapsulated in a set of Java classes that remain resident in memory for the duration of the execution, the details of which will be discussed in greater detail below.  
     [0045] EJB container  48  represents an application or set of applications that provide a set of functionality to web container  44 . The functionality of the applications is provided by one or more EJBs. The functionality of the applications is provided by one or more EJBs, as implemented by Java classes.  
     [0046] EJB container  48  has a container-provided stub  92  for channeling calls directed at a particular entity bean  96  from a set of one or more entity beans  96  in EJB container  48 . Entity beans  96  are comprised of a set of Java classes that can include a number of methods and attributes that are accessible via home interface  76  and component interface  84 , via stub  92 .  
     [0047] EJB container  48  also contains a policy manager  100  that is responsible for determining access rights of a particular user logged-in to system  20 , and who is generating a particular access request. Policy manager  100  is implemented as a stateless session bean, and as such can obtain logged-in user information portion of the security characteristics of any given call from the session context, as provided by EJB container  48 . In turn, these access rights are used, (in conjunction with the access rules in supplementary access control rules  68 ), to determine whether a particular access request is authorized.  
     [0048] In the present embodiment, policy manager  100  is a set of Java classes in EJB container  48  with one or more methods providing the logic and functionality that are employed to determine the access rights of an access request for target EJB  96  on behalf of a logged-in user. By placing this functionality in EJB container  48 , security is offered for non-Web-based clients, such as remote method invocation clients, Internet Inter-ORB protocol clients, Web services clients or message-based clients. Further, by placing policy manager  100  in EJB container  48 , security is checked in the same JVM where the entity is located, increasing the performance and scalability of the security services. In other embodiments, however, it can be desired to place policy manager  100  in another Java container, such as Web container  44 .  
     [0049] A database  104  is shown connected to server  24 . Database  104  can be any one of a number of products and/or implementations for maintaining relational data. (In other embodiments, database  104  can be any other type of means for maintaining persistent information storage, such as products or implementations for hierarchical or object-oriented databases.) In a particular embodiment of the invention, database  104  is run on a database server executed on a separate computer, such as Microsoft SQL Server or Oracle  8 i. Server  24  is in communication with database  104  via a suitable protocol such as the Java database connectivity (JDBC) protocol. While database  104  is shown as being external to server  24 , it will be understood by those of skill in the art that database  104  can reside on server  24 , and can even reside within the same JVM as EJB container  48 .  
     [0050] Database  104  stores user account information and persistent data for use with the application functionality of EJB container  48 . In particular, database  104  includes information that is represented within one or more entity beans  96 . Further, database  104  stores access rights about which entities, as represented within one or more entity beans  96 , a user can access and with what role.  
     [0051] Referring now to FIG. 3, a method for providing entity-based security will now be explained. In order to assist in the understanding of the method in FIG. 3, and to provide further understanding of system  20 , the explanation of the method shown in FIG. 3 will be discussed with reference to the embodiment shown as system  20  in FIGS. 1 and 2. (It is to be understood that the method of FIG. 3 can be implemented on other systems, however, and that system  20  can be operated in different ways.)  
     [0052] Referring first to step  210 , a call directed at a particular entity bean  96  is received. In the particular embodiment shown in FIG. 2, Web browser  36  running on client machine  28  requests an HTML page  40 . This request is addressed to server  24  which, in turn, directs the request to servlet  52 . Servlet  52  can request information by requesting either home interface  76  or component interface  84  of entity bean  96  and making calls via these interfaces. Servlet  52  initiates communication with entity bean  96  by making a call to service locator  56  for home interface  76 . Where servlet  52  is already in communication with home interface  76  of entity bean  96  through EJB proxy  60 , servlet  52  can call component interface  84  of entity bean  96 . Where servlet  52  makes a call requesting an interface of an EJB, the call is directed through service locator  56 . In this way, no actual EJB interface is provided directly to servlet  52 , thus ensuring that authorization security is enforced. For purposes of illustration, it will be assumed that servlet  52  is initiating communication with entity bean  96  at this point.  
     [0053] Upon receipt of a call for home interface  76  respective to entity bean  96 , service locator  56  generates an instance of home interface  76  of container-provided home proxy  80  of entity bean  96 . As previously discussed, service locator  56  is analogous to a DNS lookup for Internet addresses in that service locator  56  allows the use of user-friendly aliases. Thusly, service locator  56  provides EJB proxy  60  as a substitute for home interface  76  using a local service locator pattern implementation in Web container  44 . EJB proxy  60  implements the same interface as home interface  76  and thus appears to servlet  52  the same as home interface  76  for container-provided home proxy  80 . Container-provided home proxy  80  serves as an interface for the home interface of entity bean  96  that resides in EJB container  48 . (Where a call is received for a component interface  84  respective to entity bean  96 , the foregoing can be suitably modified to provide an EJB proxy  60  respective to component interface  84 , to thereby provide servlet  52  with transparent access to component interface  84 . Furthermore, it is also possible that a call is being made at step  210  wherein an EJB proxy  60  has already been created in response to a previous call on the same home interface  76  or component interface  84 , in which case the relevant EJB proxy  60  need not be recreated.)  
     [0054] At step  220 , a call from servlet  52  to entity bean  96  is intercepted by EJB proxy  60 . As service locator  56  returned EJB proxy  60  to servlet  52  upon request for home interface  76 , servlet  52  communicates with EJB proxy  60  as it would have with home interface  76 .  
     [0055] At step  230 , it is determined whether the call on home interface  76  is authorized. In the present embodiment, EJB proxy  60  handles the determination as to whether the call is authorized for a user upon whose behalf the call was made. EJB Proxy  60  extracts security characteristics from the call in order to make the determination. The security characteristics can include any number particular attributes of the call, including, but not limited to: a) the type of call that is made; b) the identity of the logged-in user on whose behalf the call was made, (“principal”), which can be extracted by obtaining state information maintained from the time that the user logged in.  
     [0056] As best seen in FIG. 4, a method of performing the determination at step  230  in accordance with an embodiment of the invention is shown. At step  231 , EJB proxy  60  provides the security characteristics to an access control manager  64 .  
     [0057] At step  232 , access control manager  64  obtains any access rules relevant to the security characteristics that were received at step  231 . In the present embodiment, access control manager  64  obtains access rules from supplementary access control rules  68  for any rules specific to the call made by servlet  52 . The types of rules are not specifically limited, and there are any number and combination of security characteristics of a call to entity bean  96  for which access control that is at least partially entity-based can be based  
     [0058] At step  233 , access control manager  64  examines the access control rules obtained at step  231  and makes an initial determination as to whether to approve or reject the call. This initial determination can be made in a variety of ways. In a present embodiment, it is assumed that system  20  follows the bureaucratic rule “if a call is not explicitly allowed, then it is forbidden”. Accordingly, the initial determination at step  233  is made by examining the access control rules obtained at step  232  and comparing those rules with the relevant security characteristics of the call obtained at step  231 . For example, if there is an access control rule that states “allow call of type ‘A’ for everyone”, and the type of call that was received at step  210  was a call of type ‘A’, then at step  233  an initial determination will be made that “Yes” the call is approved, and the identity portion of the security characteristics can be ignored. At this point, the method advances to step  238 , at which point the call is “approved”, and such approval is passed back to step  230  on FIG. 3.  
     [0059] However, if, at step  232 , there is an access control rule that states “allow call of type ‘B’ for only certain people”, and the type of call that was received at step  210  was a call of type ‘B’, then at step  233  an initial determination will be made that “No” the call is not approved, and the identity portion of the security characteristics will be deemed relevant, and the method will advance to step  234  so that a further determination as to whether to approve or reject the call can be made.  
     [0060] At step  234 , access control manager  64  queries policy manager  100  for authorization to make the call. In a present embodiment, the user information from the security characteristics of the call is obtained by policy manager  100  as part of the overall the session context that is provided by the EJB container  48 . (In another embodiment of the invention, presently less preferred, it is possible for access control manager  64  to directly pass security characteristics of the call to policy manager  100 , including the identity of the logged-in user on whose behalf the call was made.)  
     [0061] At step  235 , policy manager  100  queries database  104  whether the logged-in user has access rights to entity bean  96  and with what roles. In the present embodiment, the primary function of policy manager  100  is to determine the authorization of the call, given the subset of supplementary access control rules  68  pertinent to the call provided by access control manager  64 , and the identity of the logged-in user on whose behalf the call was made. Policy manager  100  queries external database  80  via JDBC or any other suitable means. In a present embodiment, database  104  can maintain role and entity access information for all users of system  20  in a table, but it is to be understood by those of skill in the art that this information can be maintained in a variety of other ways. Database  104  returns to policy manager  100  whether the logged-in user can access the entity represented by entity bean  96  and with what roles. Those of skill in the art will now recognize, however, that step  235  can be streamlined by having policy manager  100  keep a cache of the data in external database  80 , rather than accessing external database  80  each time policy manager  100  needs to make an authorization determination.  
     [0062] At step  236 , policy manager  100  then verifies that the logged-in user has access to entity bean  96 , and then proceeds to compare the roles with which the logged-in user can access the entity, with each set of authorization criteria for the supplementary access control rules  68  received at step  232 . In a particular embodiment, the authorization criteria are positively declared and, upon satisfaction of any of the sets of authorization criteria, the matching process is terminated. If the user&#39;s information satisfies the authorization criteria, policy manager  100  determines that the call is authorized. Where the user&#39;s information does not satisfy the authorization criteria, policy manager  100  determines that the call is not authorized (i.e. rejected.)  
     [0063] At step  237 , policy manager  100  responds as to whether the call is authorized to access control manager  64 , by passing the authorization or rejection result determined at step  236 . The method then advances from step  237  to step  238 , and the “authorization” or “rejection” response is provided to EJB proxy  60 . The method in FIG. 4 at step  238  then returns this “authorization” or “rejection” determination back to step  230  in FIG. 3.  
     [0064] While the method in FIG. 4 reflects a specific embodiment of the invention, it is to be understood by those of skill in the art that other methods of authorizing the call can be used.  
     [0065] Referring again to FIG. 3, if the response received by EJB proxy  60  at step  230  is negative (i.e. a “rejection” received from step  238  in FIG. 4), then the method advances to step  270 . At step  270 , EJB proxy  60  generates a negative response, rejecting the call. In a particular embodiment of the invention, EJB proxy  60  generates an exception. EJB proxy  60  then returns the negative response to the requester, servlet  52 , at step  280 .  
     [0066] If however, the response received by EJB proxy  60  at step  230  is positive (i.e. an “authorization” received from step  238  in FIG. 4), the method advances to step  240  where EJB proxy  60  proceeds to make the call to entity bean  96 . Such a call is made via EJB proxy  60  in the usual manner, as will be appreciated by those of skill in the art. For example, this call can either be directed to container-provided home proxy  80  via home interface  76  or to container-provided bean proxy  88  via component interface  84 , depending on the particular type of call that was made at step  210 . For example, where the type of call at step  210  was an initiation of communication with entity bean  96 , then at step  240  EJB proxy  60  makes a call on home interface  76  of container-provided home proxy  80  of entity bean  96  at step  240 . As another example, where the type of call made at step  210  was a request for component interface  84  of container-provided bean proxy  88 , then at step  240  service locator  56  generates an instance of component interface  84  of container-provided bean proxy  88  and wraps it in a newly generated instance of EJB proxy  60  before returning bean proxy  88 . Other types of call completions at step  240  will occur to those of skill in the art.  
     [0067] At step  250 , a determination is made as to whether the response to the call made at step  240  is authorized. In the present embodiment, this determination at step  250  is performed in substantially the same manner as the determination made at step  230 , except that this time it is the delivery of the response to the call for which the determination is made, rather than a determination as to the authorization of the call itself. In essence, EJB proxy  60  then repeats the process of providing entity-based security on the response received at step  240 , except that entity-based security is enforced for the returned response, instead of the placed call.  
     [0068] It is contemplated that performance of step  250  can be omitted in other embodiments, but is included in the present embodiment for situations where entity-based security is desired for responses. For example, where the results returned include a collection of objects representing data from one or more entities, it can be desired to verify that a client is authorized to access each object in the collection upon receipt of the collection by EJB proxy  60 . Access to each of the objects in the collection can be authorized before the response is provided to servlet  52 .  
     [0069] Where, at step  250 , servlet  52  is determined to be unauthorized to receive the response, the method advances to step  270 , at which point, EJB proxy  60  generates a negative response and returns the negative response to servlet  52  at step  280 . In a present embodiment of the invention, at step  280  EJB proxy  60  generates an exception and returns it to servlet  52 .  
     [0070] If, however, at step  250  servlet  250  is determined to be authorized to receive the response, the method advances to step  260 , at which point EJB proxy  60  generates a positive response at step  260 , and the positive response is returned to servlet  52  at step  280 . In a present embodiment, the positive response is comprised of the call response received from entity bean  96  by EJB proxy  60 . Thus, at step  280 , EJB proxy  60  then provides the positive response generated at step  260  to servlet  52 .  
     [0071] The method then advances from step  280  to the “End”. If another call is to be made, the method starts anew at step  210 .  
     [0072] While the foregoing discussion of system  20 , and the methods in FIGS. 3 and 4 are directed to specific implementations of the invention, it will be understood that combinations, sub-sets and variations of these embodiments are within the scope of the invention. For example, those of skill in the art will appreciate that, servlet  52  handles responses received at step  280  in the usual manner, such as passing the information from the response to a JSP for generation of a new HTML page  40  to return to client machine  28 . HTML page  40  generated by the JSP is dynamic and reflects the results of the authorization check. Where EJB proxy  60  generated a positive response at step  260 , HTML page  40  returned to client machine  28  can display information requested on a previously viewed HTML page  40 . Where EJB proxy  60  generated a negative response at step  260 , HTML page  40  can display a message that the user logged-in to client machine  28  does not possess the appropriate authority to access the requested information.  
     [0073] It will now be appreciated by those of skill in the art that the foregoing embodiments can be used in order to implement entity-based security for system  20 , and can be used to implement fine-grained security over a number of aspects and/or types of calls from servlet  52  to bean  96  using the methods of FIGS. 3 and 4.  
     [0074] Since entity beans correspond to persistent entities that could be accessed by multiple client machines  28 , simple entity-based security could be provided for a specific entity bean instance. Whenever a client calls a method on a component interface of an entity bean, the system could verify that the user on whose behalf the call is made has the appropriate authority to access this entity.  
     [0075] The entity security check for a call for a method of a component interface of an entity bean is typically performed before the EJB method call. The ability to perform an entity access check after a method call on a home or component interface also could be desirable in some situations. For example, if a method call could change the entity in a way that it would become inaccessible to the client, the security check after the method call can ensure that the entity is still accessible. If a security check after the method call fails, the client will receive a security exception and the transaction will be rolled back, but if this method performed a separate transaction or had other side effects, such side effects may remain.  
     [0076] Another form of entity-based security is the ability to check if a logged-in user can access one or more arguments of an EJB method, whether on the entity or session bean and whether on the home or component interface. Since the method arguments could represent controlled entities, such as component interfaces of other entity beans or instances of value classes, they may require access control.  
     [0077] Access control to a EJB method&#39;s arguments can be determined before the method is called, but it can be checked after the method call to ensure that the method call did not change the argument accessibility for a user on whose behalf the method call was made.  
     [0078] In a similar manner, it can be desirable for the system to control access at least partially based on a user&#39;s entity to the result of any method on the home or component interface of an entity or session bean, if the method result represents a controlled entity. In this case, it is efficient to check after the method has been called.  
     [0079] For example, this approach could be employed for the “create” method of the entity bean&#39;s home interface to ensure that the user represented by the call has access to the entities he created.  
     [0080] Another scenario where entity-based security may be used is where an EJB method result is a collection of entity bean component references. Such a collection can be returned in response to an access request that includes the findXXX or selectXXX methods on the EJB home interface and by the getXXX methods for the container-managed one-to-many or many-to-many relationships on the entity bean local component interface.  
     [0081] Similarly, the setXXX methods for container-manager relationship (CMR) fields take a collection of entities as a parameter. In such cases, entity-based access could be controlled for every entity in the collection.  
     [0082] It can be desired to control what entities a client can add or remove via the CMR field. A getXXX method for the CMR field that returns a collection could be exposed in the local interface of the entity bean. Once a client has obtained this CMR collection, it could modify the collection by adding and removing references to it. After the transaction is committed, these references will become persistent.  
     [0083] Entity beans are removed by the “remove” method call on the bean&#39;s home interface. The removal of the entity is not available neither as a method target, nor as a method parameter or result. Entity-based security can, however, be quite important to ensure that the client is authorized to remove the entity. This security check can be performed by finding the entity corresponding to the parameter passed to the remove method (either the primary key or handle), and check the client&#39;s authority before performing the “remove” method.  
     [0084] The foregoing cases describe different examples of different types of entity-based security. Supplementary security that can include entity-based rules can be enforced independent of, or in addition to, the regular J2EE role-based security. In some cases, however, these two access control methods are not orthogonal; that is, a client could have a “modify” access to some instances of a given entity bean, but only “view” to other instances of it. In such cases, it may be desirable to combine both entity-based and role-based security. Using the present invention, entity-based access rules can be listed alongside the role-based access rules.  
     [0085] In another embodiment of the invention, the supplementary access control rules are declared in security deployment descriptor  72 , similar to the manner in which role-based access rules are declared in the container&#39;s deployment descriptor. A set of tags are defined allowing an Application Assembler or other programmer to configure entity-based security for: a) home interface and component interface methods of session and entity beans, b) the results of these methods, c) collections of entity bean references, and d) references added and removed to the CMR collection filed and the removal of entity beans.  
     [0086] An example of a set of tags used to declare the access control in security deployment descriptor  72  that reflect a specific exemplary implementation of system  20  of the embodiments shown in FIGS. 1 and 2 is included in Appendix  1 .  
     [0087] For purposes of illustration of the above-noted embodiment, a specific scenario will now be discussed, that reflects a specific exemplary implementation using system  20  and the method in FIG. 2. The users of system  20  are employees of a fictitious company and a particular application provided by the EJB container is an employee information system, in which employee information is accessed through instances of the EmployeeRecord entity bean.  
     [0088] An organizational chart for this fictitious company is shown in FIG. 5. The chart shows seven employees of the company occupying various positions in three separate departments.  
     [0089] Bill is the Chief Executive Officer (CEO) and oversees the operation of the Marketing department, of which Fred is the manager, and the Sales department, of which Mike is the manager. John and Dave are two Marketing clerks who report to Fred, and, likewise, Ed and Harry are two Sales clerks who report to Mike.  
     [0090]FIG. 6 shows a table of employees and their salaries that are maintained in database  104 .  
     [0091] For this particular example, it is desired to provide the following access controls or access rights:  
     [0092] an employee can “view” his own current annual salary  
     [0093] a manager can “create”, “view”, “modify” or “delete” the salary of any other employee in his department  
     [0094] an executive can “create”, “view”, “modify” or “delete” the salary of any employee  
     [0095] Two roles, “viewer” and “administrator”, are created for purposes of the EmployeeRecord entity beans that correspond to the records of Table 1 in FIG. 6. A “viewer” is permitted to call a method named viewSalary( ) that allows him to view a salary contained in an EmployeeRecord entity bean and an “administrator” is permitted to call methods called createSalary( ), viewSalary( ), updateSalary( ) and removeSalary( ) that allow him to create, view, modify and delete an extension contained in an EmployeeRecord entity bean. An employee who is not permitted to access a specific EmployeeRecord entity bean  96  is not provided access to that bean, nor is he assigned a role for it. These security rules can be rewritten using high-level pseudo-code as follows:  
     [0096] the user could view a salary via the viewSalary( ) method if he could access the EmployeeRecord entity bean with the “viewer” role  
     [0097] the user could create, view, update or delete a salary via the createSalary( ), viewSalary( ), updateSalary or deleteSalary( ) if he could access the EmployeeRecord entity bean using the “administrator” role  
     [0098]FIG. 7 is a table of the EmployeeRecord entity beans for each employee and the access rights, if any, provided to each employee. As Bill is an executive, he has the ability to create, view, update and delete salaries of any EmployeeRecord entity bean. As Fred is a manager of the Marketing department, he has the ability to create, view, update and delete salaries of the EmployeeRecord entity beans of employees in the Marketing department, excluding himself. Likewise, Mike as the Sales manager has the ability to create, view, update and delete salaries of the EmployeeRecord entity beans of employees in the Sales department, excluding himself. Each of John, Date, Ed and Harry have the ability to view their own current annual salaries via the EmployeeRecord entity bean.  
     [0099] Data for an employee is maintained by database  104  and accessed through an entity bean called EmployeeRecord of which an instance is generated upon receipt of an access request. In generating an instance, EJB container  48  queries database  104  for an employee&#39;s information that is then encapsulated in entity bean  96 . In this scenario, servlet  52  provides users the ability to create, view, update and delete the salary of an employee.  
     [0100] The configuration code provided in Appendix  2  is generated from this pseudo-code and placed in the entity-based security descriptor.  
     [0101] Security deployment descriptor  72  is then converted into security java classes that are encapsulated in supplementary access control rules  68  during application deployment in Web container  44 .  
     [0102] When John wishes to look up his current annual salary, John opens browser  36  and selects the uniform resource locator (URL) associated with servlet  52  executing on server  24 . John then logs in on an HTML page generated by servlet that is served to browser  36 . Upon receipt of a valid login ID and password and upon selection of a hyperlink to a page providing employee information application functionality, servlet  52  serves browser  36  an HTML page  40  that allows John to select a user and an action to view his own information. Upon John&#39;s selection of this option, browser  36  sends a request to servlet  52  specifying the requested user and action. In a first instance, John requests to view his salary. Upon receipt of this request, servlet  52  calls home interface  76  of container-provided home proxy  80  that accesses the home interface of entity bean  96  located in EJB container  48 .  
     [0103] Service locator  56  receives this call for home interface  76  of entity bean  96 . In the same manner as noted previously, service locator  56  generates an instance of home interface  76  and container-provided home proxy  80 . Service locator  56  then wraps home interface  76  with a newly generated instance of EJB proxy  60  and returns it to servlet  52 . Servlet  52  then requests access to entity bean  96  through which the employee data of John is accessed.  
     [0104] This call for entity bean  96  is intercepted by EJB proxy  60 . Upon receipt of this request, EJB proxy  60  sends a request to service locator  56  for entity bean  96 . Service locator  56 , in turn, requests EJB container  48  to generate an instance of entity bean  96  containing John&#39;s employee data. EJB container  48  queries database  104  and obtains John&#39;s employee data information and encapsulates it in a newly generated instance of entity bean  96 . EJB container  48  then directs Web container  44  to generate an instance of this bean, container-provided bean proxy  88 .  
     [0105] At step  210 , service locator  56  then wraps component interface  84  of container-provided bean proxy  88  in a newly generated instance of EJB proxy  60  and returns it to servlet  52 . In this example, there are no access controls on the request for component interface  84  and, as such, no access control checks are performed thus far.  
     [0106] Servlet  52  then calls the viewSalary( ) method on entity bean  96 . At step  220 , EJB proxy  60  intercepts this call.  
     [0107] At step  230 , EJB proxy  60  determines whether the viewSalary( ) method call is allowed. At step  231 , EJB proxy  60  passes information about the call to access control manager  64 . Access control manager  64  then obtains the set of rules associated with this call from supplementary access control rules  68  at step  232 . In this case, access control manager  64  is provided the following criterion which must be satisfied for this call to be authorized: the logged-in user (in this case, John) can access John&#39;s EmployeeRecord entity with the role of “viewer” or “administrator”.  
     [0108] At step  233 , access control manager  64  determines that there are relevant access controls for this call. At step  234 , access control manager  64  then queries policy manager  100 , providing the criterion obtained in step  232  and security characteristics, including the “principal”, or identifier associated with the login ID for the user of the client.  
     [0109] Upon receipt of this query from access control manager  64 , at step  235 , policy manager  100  queries database  104 . In this case, each employee&#39;s access rights for each of the seven employees&#39; EmployeeRecord entity bean are stored in a user database presented in Table 2 of FIG. 7. Policy manager  100  determines that John has the role of “viewer” for his own EmployeeRecord entity bean.  
     [0110] Policy manager  100  then compares the security characteristics with the access rules provided. In this case, as John has the role of “viewer” for the requested EmployeeRecord entity bean, policy manager  100  determines that this call is authorized.  
     [0111] At step  236 , policy manager  100  then returns this affirmative response to access control manager  64  which, in turn, provides it to EJB proxy  60 .  
     [0112] At step  240 , EJB proxy  60  calls the business method viewSalary( EmployeeRecord), which accesses John&#39;s EmployeeRecord entity bean  96 .  
     [0113] Upon receipt of a response from entity bean  96 , component proxy  84  passes it to EJB proxy  60 . At step  250 , EJB proxy  60  queries access control manager  64  to determine if the response provided is authorized for return to servlet  52 . In this case, as the response consists of John&#39;s salary, access control manager determines that this response is authorized for return to servlet  52  as there are no access controls on the return of this kind of information to an outside party. As such, access control manager  64  provides a positive response to EJB proxy  64  which, in turn, provides John&#39;s salary to servlet  52 .  
     [0114] Upon provision of John&#39;s salary to servlet  52 , the method is completed. Servlet  52  then delegates the appropriate information to a JSP for generation of an HTML page displaying John&#39;s salary for transmission back to client machine  28 .  
     [0115] When John wishes to look up the salary of Dave, an employee in another department, the process followed is the same as in the previous example for steps  210  to  234 . At step  235 , however, policy manager  100  queries database  104  and determines that John does not have the right to access Dave&#39;s EmployeeRecord entity bean. As John does not satisfy the relevant access rules and access rights, policy manager  100  determines that the call is not authorized.  
     [0116] At step  236 , policy manager  100  returns a negative response to access control manager  64  that, in turn, provides a negative response to EJB proxy  60 . As such, at step  270 , EJB proxy  60  generates an exception and returns it to servlet  52 . Servlet  52 , in turn, directs a JSP to generate a page that indicates that the request is not authorized.  
     [0117] When Mike wishes to modify Ed&#39;s salary, the process is similar to the case where John wishes to view his own salary, with certain variations. As the kind of access is different than in the previous example, at step  232 , access control manager obtains a different set of rules from supplementary access control rules  68 . In this case, access control manager  64  is provided with the following criterion which must be satisfied for this call to be authorized: the logged-in user is able to access Ed&#39;s EmployeeRecord entity bean with the role of “administrator”. At step  235 , policy manager  100  queries database  104  and determines that Mike can access Ed&#39;s EmployeeRecord entity bean with the role of “administrator”. As such, the first access criteria for the updateSalary (EmployeeRecord, xxxxx) business method are met and policy manager  100  determines that the call is authorized. At step  260 , EJB proxy  60  provides servlet  52  the ability to modify Ed&#39;s extension.  
     [0118] When Mike wishes to modify the salary of Dave, an employee in another department, at step  235 , policy manager  100  determines that Mike can not access Dave&#39;s EmployeeRecord entity bean and, as a result, returns a negative response to access control manager  64  that, in turn, responds negatively to EJB proxy  60 . EJB proxy  60  generates a negative response, in this case by throwing an exception, and provides it to servlet  52  at step  270 .  
     [0119] While the above embodiment describes the generation of a set of Java classes that capture the rules set out in the security deployment descriptor, there are other methods by which entity-based security specified in the security deployment descriptor can be enforced.  
     [0120] It is to be understood by those of skill in the art that the method of this embodiment can be performed as part of the deployment operation or separately prior to the deployment operation.  
     [0121] While the embodiments discussed herein are directed to specific implementations of the invention, it will be understood that combinations, sub-sets and variations of the embodiments are within the scope of the invention. For example, the security rules contained in the security deployment descriptor can be placed in the container&#39;s deployment descriptor.  
     [0122] It is to be understood that the EJB proxy  60  (and variations thereof) is portable and can be implemented on any J2EE server.  
     [0123] Furthermore, in other embodiments of the invention implementing EJB proxy  60 , it is contemplated that EJB proxy  60  (or a variation thereof) can be operable to intercept calls between a session bean in an application facade layer, and an entity bean in a persistence layer.  
     [0124] It also contemplated that proxy  60  can be modified to wrap EJB method call results, in addition to, or in lieu of, the implementation of proxy  60  discussed with reference to system  20  which intercepts calls. Such a modified implementation of proxy  60  can apply to home and component interface methods, including CMR field accessor methods.  
     [0125] It is contemplated that proxy  60  (and variations thereof) can be used to accommodate special treatment of CMR collection field accessor methods, such that transparent security for such fields is offered to the developer or programmer.  
     [0126] By the same token, it is also contemplated that a clean interface between the EJB proxy and its ‘listeners’ (i.e. components interested in the interception of EJB calls) can be provided. In this particular situation, it is additionally contemplated that any other EJB proxy functionality (such as logging) can be combined with the entity-based security functionality of EJB proxy  60  described in relation to system  20 .  
     [0127] Furthermore it is contemplated that the teachings herein, including the particular teachings of proxy  60 , can be combined with any other uses of proxies, such as logging. For example, where it is desired to use proxy  60  for entity based security, proxy  60  can also having logging functionality applied thereto, so that each security check performed by proxy  60  of a particular access request can be logged for future reference.  
     [0128] It is contemplated that all security could be enforced after the call is made but prior to providing the response to the client.  
     [0129] While, for purposes of illustration, the servlet acts as a client, it is understood by those of skill in the art that other applications can be substituted.  
     [0130] While the embodiments presented herein have been described with particularity to Java, it is understood by those of skill in the art that the invention can apply to other programming environments.  
     [0131] The above-described embodiments of the invention are intended to be examples of the present invention and alterations and modifications may be effected thereto, by those of skill in the art, without departing from the scope of the invention which is defined solely by the claims appended hereto.