Patent Application
20050262487
This invention relates to security requirements for software. More specifically, the invention relates to access rights in composed software and components, particularly used in enterprise applications.
Composed software systems comprise multiple, possibly heterogeneous, and potentially distributed components. As such, they present special security requirements. In particular, security requirements may vary component by component depending on the resources that each component attempts to access. Components are software or data elements that have contractually specified interfaces, conform to a standard model, and can be independently deployed and composed without modifications according to the composition standard. These data elements include, but are not limited to, static files such as HTML, XML, or static image files, as well as multimedia resources such as video and audio files. Some components may be a combination of data and software, such as HTML documents containing JavaScript code. Some components may be the result of composition of other components.
Traditional software systems employ user- or principal-based access control models that protect systems from malicious entities, but do not take into account the location from which the component is coming and the owners or authors of the code. In contrast, the security architecture of some modern software systems does consider the heterogeneous nature of these systems. Component-based systems, such as Java 2, Enterprise Edition (J2EE) and Microsoft .NET, allow system administrators to manage authentication and authorization to access protected resources based on the principal running the code. However, other component-based systems may also perform authentication and authorization based on the origin of the component, which may include the owners or authors of the component.
Another difference between the security of some traditional software systems and that of modern enterprise systems involves authorization granularity. In traditional systems, authorization is coarse, comparatively speaking. System administrators grant either full access to the system resources or no access at all. The authorization models for recent component-based systems have been designed to be fine-grained. This means that system administrators can specify in detail which operations code can and cannot do, based on the component's origin and/or the principal running it. For example, a system administrator can decide that all components coming from a particular network location, digitally signed by certain entities and run or used by specified principals are granted access only to a particular file in the file system. Additionally, it is even possible to specify, for example, that the type of access is limited to read-only access, while authorization for write, delete, and execute access is denied.
As enterprise systems have evolved, the type of resources that are protected has also changed. In traditional systems, authorization was focused on protecting local system resources, such as the file system, operating system, network, etc. Modern component-based systems, such as the Java 2, Enterprise Edition (J2EE) and Microsoft .NET platforms, allow system administrators to protect other resources. For example, it is possible to specify that access to a certain Uniform Resource Locator (URL), Universal Resource Identifier (URI) or a family of URLs and URIs matching a certain pattern is allowed only to a particular principal or class of principals. Similarly, it is possible to specify that certain functions in a particular software component (for example, the method transferMoney( ) on a BankAccount software component) can be invoked only by a particular principal or set of principals.
For example, the J2EE security architecture defines a class of resources that are protected. In J2EE, it is possible to protect specific Web resources, such as URLs as well as Enterprise JavaBeans (EJB) methods. It is possible to specify that a particular EJB method can be accessed only by principals who have been granted a specific security role. A security role is a semantic grouping of access rights assigned to principals of an enterprise system. So, for example, it is possible to specify that method method1( ) in enterprise bean Bean1 can be accessed only by those principals who have been assigned the role of Professor. If user “bob” successfully logs in and attempts to execute, directly or indirectly, method1( ) in the enterprise bean Bean1, the method invocation will succeed only if “bob” has previously been assigned the role of Professor. The Microsoft .NET authorization model is very similar.
Both J2EE and Microsoft .NET promote the concept of declarative security. This means that it is not necessary to embed authentication and authorization code within an application. Rather, the security information is stored with other deployment information in configuration files that are external to the application code. In J2EE, such configuration information is known as deployment descriptors. A system administrator deploying Bean1 must be aware that its method1( ) can only be accessed by principals assigned the role of Professor, and will have to assign that role to users accordingly.
Problems with the Prior Art
Problems arise in complex enterprise applications. Specifically, enterprise bean methods call each other, resulting in long call chains. In the example of
The following listing shows the J2EE deployment descriptor fragment that protects method1( ) in enterprise bean Bean1 so that only principals who have been granted the role of Professor can invoke method1( ):
Similarly, the following listing shows the J2EE deployment descriptor fragment that protects method2( ) in enterprise bean Bean2 so that only principals who have been granted the role of Student can invoke method2( ):
In a J2EE environment, if user “bob” has not been additionally granted the role of Student or if the appropriate J2EE “run-as” security policy has not been specified, an error similar to the following will be generated:
The error reported often does not give enough information to understand why the method invocation failed. The system administrator can perform an analysis to determine the reason of the authorization failure. The system administrator can check the deployment descriptor associated with the Bean1 enterprise bean, see that method1( ) can be accessed only by users who have been granted the role of Professor, and verify that user “bob” was granted the role of Professor. Understanding the reason of the failure may require reading the deployment descriptors and source code of all the methods in the enterprise bean method call chain. This is a difficult, tedious, and error-prone task. Additionally the source code is not always available, as it may have been written by different software developers or organizations and composed to create the deployed application.
The situation becomes even more confusing if method1( ) on a Bean1 instance invokes method2( ) on a Bean2 instance locally (without using the RMI-IIOP protocol). In this case, the underlying J2EE system is not required to check the security roles for access to method2( ) and the method invocation will succeed even if “bob” was not granted the role of Student. The difference in behavior between local and remote method invocations makes it even harder for system administrators to figure out the authorization requirements.
Dynamic analysis is limited because it relies on having a complete set of test cases covering all possible paths through the set of components in an application. In the absence of a complete set of test cases, authorization failures may remain undiscovered until the code is deployed in the enterprise, rendering the enterprise code unstable.
Aspects of the Invention
An aspect of this invention is an improved system and method to find authorization requirements and/or policies for enterprise applications.
An aspect of this invention is an improved system and method to find authorization requirements and/or policies for enterprise applications without requiring a comprehensive set of test cases that exercise all execution paths in a set of components that comprise an application.
An aspect of this invention is an improved system and method to assist developers, system administrators, deployers, and others involved in defining and configuring security policies for an application comprised of one or more software components.
An aspect of this invention is an improved system and method that assists in defining security policies that conform to the “Principle of Least Privilege”.
The present invention provides a system, method, and apparatus for implementing a new mechanism that assists in detecting the authorization requirements and defining the security policies for an application comprising one or more components. One preferred embodiment of this invention uses a call and resource-access graph to model all the possible paths of execution of the application at runtime. Then, the invention combines the paths of execution detected during the analysis with the access control information found in the security policy of the application. Finally, for each authorization point in the application, the invention reports a minimal security policy that the executing principal should be granted in order to successfully pass the authorization test.
These and other aspects, features, and advantages of the present invention will become apparent upon further consideration of the following detailed description of the invention when read in conjunction with the drawing figures, in which:
With embodiments of the present invention, it is possible to analyze an application and detect its authorization requirements statically, which means that it is not necessary to run the application. Since the application is not executed in this analysis phase, malicious application code cannot harm the system on which the application code is analyzed. Additionally, the present invention does not require any test case and relieve system administrators, deployers, developers, and all the others involved in defining the application's security policy from the burden of manually inspecting the application in order to detect the application's authorization requirements.
Rather than relying on dynamic analysis, this invention presents a static analysis technique for automatically computing security authorization requirements in existing enterprise code. While the analysis techniques described in this introduction are in the context of J2EE application code, the basic techniques are applicable to access control analysis issues in non-Java component-based systems, including Microsoft .NET.
Frequently, a servlet or JSP application needs to interact with a database or another backend system before being able to provide the client with dynamic content. The J2EE specification recommends embedding the business logic of an enterprise application into Enterprise JavaBeans (EJB) components 206. EJB components are Java programs running on an EJB container 205 and accessible through the RMI-IIOP protocol. EJB components can also be accessed directly from a J2EE client using RMI-IIOP.
The flow chart in
Since each node in the call and resource access graph corresponds to a URL/URI or enterprise bean method invocation, security authorization information is associated with each node in the call and resource-access graph (303) using an association process 303. For example, in the scenario described in
At this point, the server/user interaction process of
1. Choose to assign the security role of Student to the principal invoking method1( ) (432). In a more general case, this means that some users must be granted additional authorizations (432). This is the scenario depicted in
2. Replace the principal's security credentials at the point of invoking method2( ) with the security credentials of a principal who has already been granted the role of Student (434). In a more general case, this means replacing the authorizations under which some resources are accessed (434).
3. Redesign the application or take other actions if 1. and 2. violate the intended security design objectives or policy (436).
In some cases, the analysis may reveal that some users were granted too many roles, a situation that violates the “Principle of Least Privilege”. In such cases, the recommended action is to grant those users only the roles that are strictly necessary to run the application. Therefore, those users will have to be granted fewer roles (438).
In other cases, the analysis may confirm that the security policy was well defined, and that all the users were granted exactly those roles strictly necessary to run the application. In such cases, the system administrator will not have to take any action (430), and will be reassured that the security policy is neither too restrictive (which would make the application unstable) nor too permissive (which would make the application unsecure).
Specifically,
This invention enhances the security and stability of enterprise applications. This invention considers all the possible execution paths within the application. This implies that if there is an execution path for which a particular security role is required, that execution path is discovered during the analysis, and the system administrator can choose whether to grant the necessary security role. No runtime path will be excluded by the static analysis. This improves code stability and eliminates the potential authorization failures that would be generated at runtime. In most cases, alternative solutions, such as manually examining the code or performing dynamic analysis of the code, do not ensure that all the possible invocation paths have been examined, especially when the code being analyzed is large and complex, and the invocation paths depend on inputs from the user.
Additionally, assuming a sufficiently precise control flow analysis of the software components, this invention assists in enforcing the security rule known as the “Principle of Least Privilege” by correctly identifying the minimal set of security roles that need to be assigned to the principals attempting access to the applications. The present invention extends to the J2EE environment the invention of access rights analysis for J2SE applications, described in U.S. patent application entitled AUTOMATED PROGRAM RESOURCE IDENTIFICATION AND ASSOCIATION to Koved et al. filed on May 11, 2001, Ser. No. 09/854,031, which is herein incorporated by reference in its entirety.
The present invention provides a method and apparatus for determining which security roles a principal must be assigned to access components or collections of components in an enterprise application. An enterprise application, including some or all of its components, is analyzed by performing static analysis on the components and configuration information. This may include analyzing components that could be accessed locally or remotely. Typically, the result of the static analysis is a call and resource-access graph. Each node in the call and resource-access graph represents a method or resource; if nodes A and B in the call and resource-access graph are connected by an edge, that means that accessing the method or resource represented by A leads to accessing the method or resource represented by B. From the application security policy and/or the components, the security roles associated with each component and resource are identified from existing configuration information. Those are the security authorizations or roles that must be granted to a principal accessing the resources. Note that configuration information can be deployment descriptors, security policies, XML files, application settings, a configuration database, or any other stored information that is used by the application during the execution of the application.
It is possible to use context sensitivity to reduce the conservativeness of the analysis and potentially minimize the number of authorizations that would be identified to be required by the principal invoking a component (such as a URL/URI or EJB method).
One preferred propagation process (304) used to achieve the purpose of the present invention involves using fixed-point iteration. All the nodes of the call and resource-access graph are put into a work queue. (In a preferred embodiment only the nodes on which authorization test are performed are put into the work queue.) Each node in a call and resource-access graph has a set of security roles associated with it. Initially, each set either is empty or contains the security roles necessary to access the resource as specified in the deployment descriptor associated with the resource represented by the node. A resource is a element of a component that can be accessed and used as part of an application. Examples of resources include methods or procedures on software, URL/URI, text, images, XML, and files. Using fixed-point iteration, the nodes are extracted from the work queue one by one. For each node n, the set of its predecessors is identified. Each predecessorp of n is examined. If the edge fromp to n represents a remote method invocation and if the deployment descriptors did not specify in a “run-as” policy that the security credentials of the principal invoking n should be replaced with the security credentials of another principal whose security role is in n's set, then the set of security roles currently associated with n is unioned with the set of roles currently associated with p, and the set of security roles resulting from this set union operation is associated with p. If the set of security roles associated with node p has changed because of this operation, then p itself is put into the work queue, ifp is not already there. This process is guaranteed to terminate because the universe of all the roles associated with an enterprise application is finite. Furthermore, this process terminates only after having mapped each node with the set of security roles required to access that node's resource.
Using the security role propagation algorithm just described, the system administrator is able to detect that the original security failure was due to user “bob”'s lacking the role of Student when invoking method1( ). With this invention it is possible to determine the required security roles without having to run the application.
In conclusion, the algorithm presented by this invention identifies the security roles needed to execute a component-based application. This information can be used to improve the security, usability, and reliability of those enterprise applications without violating the “Principle of Least Privilege”.
