US20070282841A1 - System and method for role based analysis and access control - Google Patents

System and method for role based analysis and access control Download PDF

Info

Publication number
US20070282841A1
US20070282841A1 US11/446,104 US44610406A US2007282841A1 US 20070282841 A1 US20070282841 A1 US 20070282841A1 US 44610406 A US44610406 A US 44610406A US 2007282841 A1 US2007282841 A1 US 2007282841A1
Authority
US
United States
Prior art keywords
role
typestate
program
access
recited
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/446,104
Other versions
US7933925B2 (en
Inventor
Vugranam Chakravarthy Sreedhar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/446,104 priority Critical patent/US7933925B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SREEDHAR, VUGRANAM CHAKRAVARTHY
Publication of US20070282841A1 publication Critical patent/US20070282841A1/en
Priority to US12/196,682 priority patent/US8543607B2/en
Application granted granted Critical
Publication of US7933925B2 publication Critical patent/US7933925B2/en
Priority to US13/668,918 priority patent/US20130067592A1/en
Priority to US13/966,574 priority patent/US9785799B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine

Definitions

  • the present invention relates to access control of programs and more particularly to systems and methods for role based security and role based security analysis.
  • J2EETM Java 2 Enterprise EditionTM
  • MICROSOFTTM XML Web Services platform .NETTM
  • the security model of J2EETM and .NETTM are quite similar, and for simplicity examples herein will employ the JavaTM programming language.
  • J2EETM and the JavaTM programming language are trademarks of SUN MICROSYSTEMSTM.
  • .NETTM is a trademark of the MICROSOFT CORPORATIONTM.
  • a system and method for program access control includes, for a typestate, providing typestate properties and assigning a role to the typestate in a program in accordance with the typestate properties. Access to operations is limited for the typestate in the program based on the role assigned to the typestate and an access permission level.
  • FIG. 1 is an illustrative observer pattern program used as an example for demonstrating present principles
  • FIG. 2 illustratively shows code for role definitions in accordance with an illustrative embodiment
  • FIG. 3 is a call graph for the program depicted in FIG. 1 ;
  • FIG. 4 is an illustrative pointer graph for the program depicted in FIG. 1 ;
  • FIG. 5 is an application model showing entry methods and role assignments in accordance with an illustrative example
  • FIG. 6 is an annotated call graph showing Role i and Role + role assignments for each method in accordance with one illustrative embodiment
  • FIG. 7 is a typestate diagram for a File program operation in accordance with an illustrative example
  • FIG. 8 is a hierarchical typestate diagram for the diagram of FIG. 7 ;
  • FIG. 9 is a diagram showing a role hierarchy assignment in accordance with an illustrative embodiment
  • FIG. 10 is a block/flow diagram showing a system/method for access control using typestate role assignments in accordance with one embodiment
  • FIG. 11 is a block/flow diagram showing a system/method for analyzing role consistency for program access control in accordance with illustrative embodiments.
  • FIG. 12 is a block diagram showing an illustrative system for employing role based analysis and access control in accordance with an illustrative embodiment.
  • a data-centric security system and method are presented, which include at least the following two concepts.
  • Role Analysis A simple interprocedural static analysis for detecting security problems when objects are accessed by multiple methods that do not have compatible or consistent assignment of roles is provided. Then, a notion of an object “escaping” a role is presented, and a simple interprocedural static analysis for computing the set of objects that may escape a role is provided.
  • J2EETM method-based role assignment is extended to consistency-based role assignment. One focus includes assigning roles to typestates rather than methods.
  • Role Based Access Control is a popular mechanism for defining and managing access to security sensitive resources.
  • security properties such as access control to sensitive resources, are controlled through roles. Users are assigned one or more roles, who then inherit the security properties associated with the roles.
  • RBAC provides greater security by preventing users from obtaining inconsistent or incompatible security properties.
  • J2EETM and .NETTM support RBAC by restricting the roles to method access.
  • a role r is simply a named set of methods M, and whenever a principal P is assigned the role r the principal can then access any of the methods in M. In practice only application entry methods are assigned roles.
  • J2EETTM there are two ways to specify access control security: (1) declarative or container security and (2) programmatic or application security.
  • container security access control to sensitive resources is defined in an external configuration file, as part of a deployment descriptor. The container then manages the access control to sensitive resources.
  • application security access controls are encoded within the application and the application directly manages the access control to sensitive resources.
  • J2EETM framework encourages the use of declarative security since it enables greater flexibility by separating security properties from the application logic. Declarative security will illustratively be employed in describing embodiments of the present invention. Further description will follow on systems and methods which employ these aspects and features.
  • Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both hardware and software elements.
  • the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • a computer-usable or computer-readable medium can be any apparatus that may include, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
  • a data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code to reduce the number of times code is retrieved from bulk storage during execution.
  • I/O devices including but not limited to keyboards, displays, pointing devices, etc. may be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
  • Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
  • the Observer Pattern 10 is made of two entities: (1) a subject that includes data of interest (see e.g., ISubject in FIG. 1 ) and (2) one or more observers (IObserver in FIG. 1 ) that display the data of interest.
  • the Observer Pattern 10 defines a one-to-many dependency between the subject and the set of observers. Whenever the data in the subject is updated, all the observers that have been registered with the subject for the data are notified of the update.
  • the application deployer then associates each role with a set of methods.
  • roles may include, e.g., a Notifier, a Manager, a Director, DisplayID and DisplayName.
  • the Notifier role has the permission to invoke the method setData defined in the Subject class.
  • J2EETM roles are typically defined for enterprise JavaTM beans (EJB) components rather than arbitrary classes.
  • EJB enterprise JavaTM beans
  • examples of general JavaTM classes will be employed, instead of EJB examples.
  • a principal with the Notifier role is permitted to access (that is, invoke) the method setData that is defined in the class Subject.
  • a principal with the DisplayId role is permitted to access all the methods (denoted by the “*” operator) that are defined in the class ObsId.
  • J2EETM one can use such access control specifications for other Web resources such as access to a HTTP method on a URI (Universal Resource Identifier). Also, methods that are not part of any role, are permitted to be accessed by any principal.
  • URI Universal Resource Identifier
  • RBAC role based access control
  • Access control to data and objects has to be performed implicitly by giving access to methods which in turn accesses the data.
  • An important security implication of such access control through methods is that information could potentially be leaked through data flow across methods.
  • the method ObsName.update and the method Obsid.update are part of two different roles. Therefore, when obs.update( ) is invoked at statement 43 :, the target method could be either ObsId.update or ObsName.update depending on the runtime type of obs. Since, ObsName.update and ObsId.update have two different roles, there could be a potential security problem when the method is dispatched. Therefore, it is important to ensure that both methods are assigned the same role.
  • the security problems that arise are either: (1) too many permissions are given to a principal, which in turn may violate the principle of least privilege, or (2) inadequate permissions are given, which can lead to unnecessary access control exceptions. There can be subtle security violations, such as information tainting and information leakage, when the principle of least privilege is compromised. Note that a simple propagation of roles over the call graph of the program is not sufficient to detect such data flow security problems.
  • Role Analysis A simple interprocedural static analysis for detecting security problems that may arise when objects are accessed by multiple methods that do not have compatible or consistent assignment of roles to methods is provided. The notion of an object “escaping” a role is presented and a simple interprocedural static analysis for computing the set of objects that may escape a role is described.
  • Consistency-Based Security and Role Typestates Method-based role assignments are extended to consistency-based role assignments and roles are assigned to typestates rather than methods.
  • the typestate description of a class is a configuration of its fields, and essentially abstract consistency properties of the fields.
  • Static analysis is a process for determining the relevant properties of a program without actually executing the program.
  • a program includes a collection of methods or procedures and is represented using a call graph (CG).
  • the set of nodes N is partitioned into two disjoint sets: (1) N c is a set of call site nodes and (2) N m is a set of method nodes.
  • the set of edges E is also partitioned into two disjoint sets: (1) E m,c is a set of edges from a method node x m to each call site node x c defined in the method, and (2) E c,m is a set of edges from a call site node x c to each method node x m that can possibly be invoked from the call site x c .
  • a path is a sequence of edges starting from some node in the call graph. If there is a path from a method node x m to another method node y m then the method corresponding to x m may directly or indirectly invoke the method corresponding to y m .
  • Pointer analysis includes computing points-to information, represented as a pointer graph, at relevant program points.
  • a pointer graph includes a set of nodes representing compile-time objects and pointer references.
  • pointer p can point-to an object O if p can include the address of 0 .
  • the address of O is not known at compile-time and one then assigns compile-time labels to heap objects.
  • pointer analyses There are several different kinds of pointer analyses depending on precision and cost of the analysis. Typically, flow insensitive and context insensitive analysis tends to be cheaper, but less precise than flow sensitive and context sensitive analysis.
  • a pointer graph is illustrated that is computed using a flow insensitive pointer analysis for the code of FIG. 1 , where non-bracketed numbers in FIG. 4 correspond to statement numbers in FIG. 1 .
  • the notation p ⁇ O may be employed to denote that p points-to O. It will also be assumed that objects have fields and each field has a name that can be accessed from the object type or class. Dot-notation is used to access fields, e.g., p.f or O.f , and it can be stated that: p.f ⁇ O to denote that p points to some object O 1 and the field f of O 1 points to another object O.
  • J2EETM security is defined in terms of: (1) principals or authenticated users, (2) roles that define named job functions, and (3) permissions that map a role to a set of operations or methods defined in one or more classes.
  • roles are often defined for Enterprise JavaBeans (EJBs), and for simplicity, herein, JavaTM classes will be employed instead of EJBs.
  • EJBs Enterprise JavaBeans
  • a role such as Notifier (see FIG. 2 ) is given permission to invoke setData.
  • a role such as Director is given permission to invoke all four operations. Notice that a principal with a Director role can invoke any operation that a principal with a Manager role or a Notifier role can invoke. In other words, Director is considered to be “senior” to Manager and Notifier.
  • a junior role may be defined as follows. r ⁇ s, if Per(r) ⁇ Per(s).
  • the role graph form employed in this disclosure will include a lattice structure, with ⁇ representing a role that is the union of all method permissions and ⁇ representing a role whose permission set is the empty set.
  • a lattice is a partial order with a join and a meet for every pair of nodes. Given any two nodes x and y, the set union of x and y is the join ( ⁇ ), and the set intersection of x and y is the meet ( ).
  • Per i (r) be a set of method permission that is initially assigned a role r (as specified in the deployment descriptor).
  • a method permission can be assigned to more than one role.
  • Role i (m) denote the set of roles that an application deployer initially assigns to m.
  • Role i (m) ⁇ r
  • Role i (Subject.setData) ⁇ Notifier, Director ⁇ .
  • a method is not explicitly assigned to any role, then it can be accessed by any principal. Note that one can also use the “*” to indicate all the methods in a class as belonging to a specific role.
  • Role Analysis Two illustrative role analyses are presented and include: (1) role consistency analysis for computing consistent role assignment and (2) role escape analysis for computing the set of objects that may escape a role.
  • Role Consistency Analysis Let r be a role assigned to m (by an application deployer), and let m′ be a method that can be invoked directly or indirectly from m. A principal who is assigned the role r should also have permission to invoke the method m′, i.e., m′ should also be in Per(r).
  • an application deployer handles only entry methods of an application or a component. These entry methods are essentially the application programming interface (API) of the application. In the case of a JavaTM application, the entry methods are the set of public and protected methods defined in interfaces and classes. Therefore, an application deployer has the capability to define permission sets and assign roles based on the entry methods defined in an API.
  • API application programming interface
  • A be an application
  • M e be a set of entry methods to A (as defined in its API)
  • R be the set of roles defined using the entry methods.
  • an application or component model is illustratively shown. Notice that an entry method such as m 1 can directly or indirectly invoke another entry method m 2 .
  • One question is how to define consistent roles and permission sets that are based on only the entry methods of an application.
  • r 1 defines r 1 to include ml in its permission set, that is m 1 ⁇ Per(r 1 ), and therefore r 1 E Role(m 1 ). What this essentially means is that if a principal P is assigned the r 1 , then P has the permission to invoke m 1 .
  • m 2 is not in Per(r 1 ), and in this case P should also be assigned the role r 2 so as to avoid access control exception.
  • P should also be assigned the role r 2 so as to avoid access control exception.
  • P by assigning r 2 to P, also give P the permission to access m 3 , which violates the principle of least privilege.
  • m 3 may be in a different sub-component, in which case separating the roles makes sense in some situations, even if the principle of least privilege is violated.
  • m 2 is in Per(r 1 ), and in this case the assignment is consistent.
  • Applications may be composed of many components and the components are assigned with consistent roles.
  • Role i denote the initial set of role assignments.
  • Subject.setData the principal not only needs the Notifier, but also DisplayId and DisplayName roles.
  • an annotated call graph is illustratively shown with Role i and Role + , which are the initial role assignments and the minimum roles needed to invoke the methods.
  • Computing Role + for each method is a straightforward backward propagation of roles over the call graph and at each step only propagation of junior roles up the call graph is performed. That is, a lattice join is performed at each step and the joined role information is propagated.
  • the role analysis described previously is preferably based on reachability over a call graph of a program. Although role propagation over the call graph may be important in preventing certain kinds of access control problems, it does not detect access problems that could happen due to data flow across methods.
  • a limitation of the J2EETM security model is that it focuses on securing the mechanism (that is, methods) that access sensitive information or resources. For instance, J2EETM does not allow one to specify roles for class fields and class instances. Subtle problems may arise due to data flow across methods.
  • the receiver expression (such as 43: obs.update(data) in FIG. 1 can target more than one method. Programmers have to make sure that the roles assigned to the target method are consistent with the role assigned to a method that invokes the object.
  • an object is often accessed by multiple methods that have different roles assigned to them.
  • the object 62 :ObsId This object is directly accessed by the methods Driver.main (which created the object), ObsId.update (via the “this” parameter), and Subject.notifyObs.
  • Driver.main which created the object
  • ObsId.update via the “this” parameter
  • Subject.notifyObs Now, consider the role assignment and method permission shown in FIG. 6 .
  • the method ObsId.update is assigned only to role Display.
  • the object, 62 :ObsId is also accessed by other methods, there can be inconsistencies among roles assigned to different methods that access the same object. This can lead to information leakage.
  • the set of methods are computed that directly access the object.
  • Call the resulting graph a method-annotated pointer graph (MAPG). It is straightforward to compute this information if fully qualified names are used for reference.
  • MAG method-annotated pointer graph
  • the set of methods that access this object can be read off from the pointer graph, which is Driver.main, Subject.addobs, Subject.notify, and Obsid.update. Since any of these methods have the “capability” to access the object, the object is assigned a role that is the least upper bound of the roles assigned to these methods.
  • the object 6 :bar.LinkedList created at 6 escapes the method bar because there is an access path to the object from the parameter reference h.
  • the object 2 :foo.LinkedList created at 2 : and the object 6 :bar.LinkedList created at 6 do not escape foo.
  • One simple way to compute whether an object O escapes a method M is first to construct the pointer graph and then check if there is a path to O in the graph that can be reached by some node O′ that is accessed in some other method M′ and the life time of M′ that exceeds the life time of M.
  • role escape analysis the method escape analysis may be extended as follows.
  • An object O role escapes a method M with role R if there is a path in the pointer graph from some node O′ that is accessed in some other method M′ with role R′ and R ⁇ R′.
  • an object O is role confined to a M if O does not role escape M.
  • a definition of role escape employed herein is more general than the traditional method or thread escape, whereby method lifetime is defined herein as a role.
  • the role escape analysis essentially includes determining if a node p in the pointer graph that is annotated with method m and role r ⁇ Role + (m) is reachable from another node p′ that is annotated with m′ and role r′ ⁇ Role + (m′) and r ⁇ r′.
  • Consistency-Based Security It is often the case that an application developer has a better understanding of the application that he or she is developing than an application deployer or the system administrator. On the other hand an application deployer has a better understanding of the application deployment environment than an application developer.
  • CBS consistency-based security
  • a simple consistency property could be that two fields of a JavaTM class are modified by the same set of methods.
  • Another consistency property is the typestate property, which is often used to specify ordering of methods in an application.
  • a tool can scan the code and present the developer's consistency properties to an application deployer. An application deployer can then use the consistency properties as a guide for associating security properties to roles, and then grant authorization to users.
  • Data Consistency Security a simple consistency property in which two or more fields of an object are all accessed by the same set of methods. Given this property, an application deployer can then associate the same role for all methods that access these fields. Consider a simple employee record in a company.
  • an application developer is developing a business application, such as a payroll application, and decides that gender, and ethnicity (“ethnic”) have the same “consistency property.
  • a simple example of a consistency property is that the two fields are always accessed by the same set of methods.
  • Another example of a consistency property is access rights; if a user is permitted to access one of the two data fields, then the user is automatically allowed to access the other data field.
  • Yet another example of a consistency property is encryption; the values of the two data fields should use the same encryption/decryption keys.
  • An application developer usually has a better understanding of the consistency properties than the application deployer. For instance, if gender, and ethnic are always accessed by the same set of methods, the developer can then define a simple consistency property classification called race.
  • a field can belong to more than one class of a consistency property.
  • fname first name
  • lname last name
  • a consistency property includes two parts: (1) a property name such as access and (2) a set of classifications, such as name, idy, and race.
  • An application deployer first queries the application for all application-defined properties. Next, the application deployer associates roles to consistency properties.
  • an application deployer defines two roles called Manager and NonManager, and associates the Manager role with access(name,idy,race) and NonManager role with access(name).
  • a Manager can access all the defined fields, whereas a NonManager can only access the fields fname and lname.
  • a deployer does not need to understand how a developer defined the consistency properties. The deployer only has to know what set of consistency properties have been defined by the developer.
  • Role Typestates are defined by focusing on the typestate consistency property. The approach that may be employed is very simple: an application developer defines the typestate properties and an application deployer then assigns roles based on the typestate properties. Typestates provide much richer information than simple method interfaces to an application deployer.
  • Typestate may be understood as an extension to the notion of a type by providing that a variable be in a certain state before operations on the variable can be performed. In other words, certain preconditions have to be met prior to performing any operation on a variable.
  • Typestate is useful for tracking certain kinds of flow-sensitive errors or bugs, such as uninitialized variables.
  • object-oriented ( 00 ) programs the typestate of an object (that is, an instance of a class) is a description or a configuration of all its fields.
  • a method that is invoked on an object o typically has a partial view of the object o.
  • class File ⁇ typestate Start, Open, Close // @requires Start File create(String fname) ; // create file // @requires Close void open( ) // // @requires Open String read( ) ; // returns the content of file // @requires Open void write(String data) ; // write to file // requires Open void close( ) ; // close the file ⁇
  • a typestate diagram is a finite state diagram, with nodes denoting the typestates of a class (e.g., open and close) and a labeled edges denoting transitions between typestates of a class.
  • the labels on the edges e.g., close( ), open( ), create( ), read( ), write( )
  • the source and destination nodes of a transition correspond to pre- and post-conditions of the method that labels the transition, respectively.
  • An execution of a method takes an instance of a class from one typestate to another typestate.
  • FIG. 7 illustrates a typestate diagram for the File class code (FILE OBJECT WITH TWO TYPESTATES) presented earlier.
  • the typestate diagram specifies the life-cycle of how an instance of the File class goes between Open and Close typestates.
  • a method such as open( ), is executed only when its pre-condition typestate of the File object is Close, and after the execution the new typestate of the object is Open. Both read( ) and write( ) methods can execute only when the File object is in Open state.
  • the typestate diagram is an external specification of a class. It prescribes the order in which a client can invoke various methods defined in the class. Generally, only an application developer understands the lifecycle of an object. Given such a specification, an application deployer can now associate security properties to typestates. For instance, an application deployer can associate Manager role to Start, Open and Close typestates, and Engineer role to Open. What this essentially means is that only a Manager is permitted to execute all methods of the class, whereas an Engineer is permitted to execute only read( ) and write( ) methods.
  • a typestate diagram may be partitioned into a hierarchical structure and use the notion of a hierarchical typestate diagram.
  • a hierarchical typestate diagram includes a set of states and a set of transitions.
  • a state may be composed of other states, called sub-states. This enables modeling of a complex hierarchical typestate diagram by abstracting away detailed behavior into multiple levels. States that do not include sub-states are called simple states, whereas states that have sub-states are called composite states. States may be nested to any level.
  • a transition relates two states: a source state and a destination state. Transitions are labeled and each label corresponds to a method invocation. An invocation of a method can cause a state transition.
  • the hierarchical states in a typestate diagram may induce a tree structure.
  • FIG. 8 illustrates a hierarchical typestate diagram in which the Open state shown in FIG. 7 has been expanded. For role typestates, it is natural to model roles using a tree structure.
  • Roles R 0 -R 4 are assigned to each method in the tree.
  • the definition of senior relation is simpler: r > s if r is a parent of s in the role hierarchy tree 120 .
  • Typestates are useful for modeling access patterns, including message patterns in, e.g., Web Services. Once such message patterns are modeled using typestates, roles can be assigned to states using the present principles and provide security for applications, e.g., Web Service applications.
  • the present embodiments address the challenges of role assignment and role semantics in building applications.
  • the prior art method-based access control is limiting in terms of its expressive power.
  • a data-centric security is employed to complement the method-based security.
  • Role-based access control for managing and controlling access to sensitive resources is provided.
  • RBAC models have become popular because of their generality in expressing a diverse set of access control policies.
  • Security analysis techniques are provided for ensuring that security properties are correctly maintained even in the presence of delegating administrative privileges.
  • the role analysis described herein is related to static analysis.
  • the consistency-based security and role typestate is one preferred way to extend the J2EETM model to deal with data-centric security.
  • J2SETM Java 2 Standard EditionTM
  • the security access control model is based on properties that include code origin and principal's execution environment.
  • the present disclosure follows program analysis techniques for RBAC, uses typestate properties for RBAC, and introduces the notion of role escape analysis and the notion of role typestates to model and detect security problems, e.g., in J2EETM.
  • role escape analysis generalizes the traditional escape analysis, where the method and thread lifetime are considered to be an instance of roles.
  • Role escape analysis is useful for detecting confinement properties of objects, and for detecting information leaks through objects.
  • Role typestates combine the notion of roles and typestates. By associating roles to typestates, a more general model is defined for specifying roles; instead of specifying roles on methods, the role are now specified on typestates.
  • Consistency based security that includes typestate security may be employed to complement method-based security.
  • present principles may be employed in addition to or instead of the security measures employed in the prior art environments.
  • typestate properties are determined or provided.
  • typestate properties include an association of a security property (or level) with the typestate to assign the role to the typestate.
  • a role is assigned to the at least one typestate in a program in accordance with the typestate properties.
  • a typestate hierarchy tree may be generated and roles are assigned to nodes of the hierarchy tree where the nodes represent the typestates.
  • access to operations of the at least one typestate in the program are limited based on the role assigned to the at least one typestate and an access permission level.
  • Limiting access may include denying access to the at least one typestate if a role is junior to an assigned role and/or permitting access to the at least one typestate if a role is senior to an assigned role.
  • a role consistency analysis may be performed to determine if assigning the role is consistent throughout the program.
  • a role escape analysis may be performed to determine if any program objects escape a role assignment.
  • a method-based access control method may be employed instead of or in addition to the present method for access control.
  • a block/flow diagram showing a system/method for analyzing role consistency for program access control is illustratively depicted.
  • a set of methods that directly access an object is computed. This may include generating a pointer graph of the program, such as, a method-annotated pointer graph.
  • a role assignment is checked for each object by determining if the object's role is a least upper bound of the roles assigned to the methods of the set in block 304 . Access is permitted to the set of methods if an accessor's role is at least equal to the least upper bound of the roles assigned to the methods that access the object in block 308 .
  • a role escape analysis may be performed instead of or in addition to the role consistency analysis (blocks 302 - 308 ) to determine if any program objects escape a role assignment.
  • the role escape analysis includes constructing a pointer graph for a program having a plurality of objects having assigned roles in block 320 .
  • each object O is checked to determine if 0 role escapes a role R by determining if there exists another path to that object O in the pointer graph that can be reached by some node O′ that is accessed in another role R′ and a lifetime of the method R′ exceeds the life time of R.
  • the role consistency analysis may be performed separately or in addition to the role escape analysis.
  • an illustrative system 400 includes a program access control program or module 402 capable of supporting role-based security and role-based security compliance in accordance with the present principles.
  • Program 402 is preferably incorporated into the operating system of computers, nodes and servers where access control is needed.
  • each operating system for all devices employed in the system 400 employs the role-based system of the present invention.
  • System 400 may include a private computer network, a single computer ( 409 ) or a public computer network, such as the Internet or any combination of these.
  • the role-based access control may be employed in telephones (cell phones), handheld or laptop computers (e.g., PDAs), or any other computing device or system.
  • Server 401 , computer 409 and each computer or node 404 in the network may include memory storage 403 (e.g., RAM) where an operating system 405 in conjunction with a processor 407 and communication protocols are employed to facilitate communications between network or computer users and perform the action needed for access control in accordance with present principles.
  • Nodes or computers 404 may include access points for a plurality of users to a server 401 or may include individual computers which grant or deny permission to gain access to methods 406 and/or typestates 408 stored on a computer or server 401 .
  • methods 406 and typestates 408 are shown in the server 401 and computer 409 , any or all computers 404 in the network or independent computers 409 may include methods and typestates that are under access control.
  • the methods and typestates include roles such that a principal attempting to access the method and/or the typestate can gain access to the method or typestate only if the proper permission or access level in afforded to that principal.
  • method-based access control is extended by moving to a more data-centric access control system.
  • Program 402 may be distributed over the network or located on a server; however, program or module 402 is preferably included in the operating system of individual computers or servers. Program 402 further includes features to provide for role assignment, check for role consistency and determine whether any roles assigned can be escaped as described above in accordance with present principles.

Abstract

A system and method for program access control includes, for a typestate, providing typestate properties and assigning a role to the typestate in a program in accordance with the typestate properties. Access to operations is limited for the typestate in the program based on the role assigned to the typestate and an access permission level.

Description

    BACKGROUND
  • 1. Technical Field
  • The present invention relates to access control of programs and more particularly to systems and methods for role based security and role based security analysis.
  • 2. Description of the Related Art
  • In Java 2 Enterprise Edition™ (J2EE™) and MICROSOFT™ XML Web Services platform (.NET™) roles are assigned to methods using external configuration files, called the deployment descriptors. The security model of J2EE™ and .NET™ are quite similar, and for simplicity examples herein will employ the Java™ programming language. J2EE™ and the Java™ programming language are trademarks of SUN MICROSYSTEMS™. .NET™ is a trademark of the MICROSOFT CORPORATION™.
  • Assigning roles to methods, although conceptually simple, in practice is quite complicated. For instance, in order for a deployer to assign a role r to a method m, the deployer must understand the set of roles R that are assigned to each method n that can be invoked directly or indirectly from m, and that r has to be “consistently” assigned with respect R. Understanding such role consistency is a non-trivial task. Also, in J2EE™ roles are defined with respect to method access and not data access. Therefore, in order to protect sensitive data, one has to encode data access control using method access control. This can lead to interesting and subtle access control problems when accessing sensitive data, including information leakage through data flow from one method to another.
  • SUMMARY
  • A system and method for program access control includes, for a typestate, providing typestate properties and assigning a role to the typestate in a program in accordance with the typestate properties. Access to operations is limited for the typestate in the program based on the role assigned to the typestate and an access permission level.
  • These and other objects, features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
  • BRIEF DESCRIPTION OF DRAWINGS
  • The disclosure will provide details in the following description of preferred embodiments with reference to the following figures wherein:
  • FIG. 1 is an illustrative observer pattern program used as an example for demonstrating present principles;
  • FIG. 2 illustratively shows code for role definitions in accordance with an illustrative embodiment;
  • FIG. 3 is a call graph for the program depicted in FIG. 1;
  • FIG. 4 is an illustrative pointer graph for the program depicted in FIG. 1;
  • FIG. 5 is an application model showing entry methods and role assignments in accordance with an illustrative example;
  • FIG. 6 is an annotated call graph showing Rolei and Role+ role assignments for each method in accordance with one illustrative embodiment;
  • FIG. 7 is a typestate diagram for a File program operation in accordance with an illustrative example;
  • FIG. 8 is a hierarchical typestate diagram for the diagram of FIG. 7;
  • FIG. 9 is a diagram showing a role hierarchy assignment in accordance with an illustrative embodiment;
  • FIG. 10 is a block/flow diagram showing a system/method for access control using typestate role assignments in accordance with one embodiment;
  • FIG. 11 is a block/flow diagram showing a system/method for analyzing role consistency for program access control in accordance with illustrative embodiments; and
  • FIG. 12 is a block diagram showing an illustrative system for employing role based analysis and access control in accordance with an illustrative embodiment.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • A data-centric security system and method are presented, which include at least the following two concepts. 1) Role Analysis: A simple interprocedural static analysis for detecting security problems when objects are accessed by multiple methods that do not have compatible or consistent assignment of roles is provided. Then, a notion of an object “escaping” a role is presented, and a simple interprocedural static analysis for computing the set of objects that may escape a role is provided.
  • 2) Consistency-Based Security and Role Typestates: J2EE™ method-based role assignment is extended to consistency-based role assignment. One focus includes assigning roles to typestates rather than methods.
  • Role Based Access Control (RBAC) is a popular mechanism for defining and managing access to security sensitive resources. In RBAC, security properties, such as access control to sensitive resources, are controlled through roles. Users are assigned one or more roles, who then inherit the security properties associated with the roles. RBAC provides greater security by preventing users from obtaining inconsistent or incompatible security properties. J2EE™ and .NET™ support RBAC by restricting the roles to method access. In J2EE™, a role r is simply a named set of methods M, and whenever a principal P is assigned the role r the principal can then access any of the methods in M. In practice only application entry methods are assigned roles.
  • In J2EET™, there are two ways to specify access control security: (1) declarative or container security and (2) programmatic or application security. In container security, access control to sensitive resources is defined in an external configuration file, as part of a deployment descriptor. The container then manages the access control to sensitive resources. In application security, access controls are encoded within the application and the application directly manages the access control to sensitive resources. The J2EE™ framework encourages the use of declarative security since it enables greater flexibility by separating security properties from the application logic. Declarative security will illustratively be employed in describing embodiments of the present invention. Further description will follow on systems and methods which employ these aspects and features.
  • Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both hardware and software elements. In a preferred embodiment, the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • Furthermore, the present invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that may include, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
  • A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code to reduce the number of times code is retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
  • Referring now to the drawings in which like numerals represent the same or similar elements and initially to FIG. 1, to illustrate how security roles are defined in J2EE™, an example application of an Observer Pattern 10 is illustratively shown. The Observer Pattern 10 is made of two entities: (1) a subject that includes data of interest (see e.g., ISubject in FIG. 1) and (2) one or more observers (IObserver in FIG. 1) that display the data of interest. The Observer Pattern 10 defines a one-to-many dependency between the subject and the set of observers. Whenever the data in the subject is updated, all the observers that have been registered with the subject for the data are notified of the update.
  • In J2EE™ the security roles are defined within an assembly descriptor as shown below:
  • <assembly-description>
    <security-role>
      <role-name> Manager </role-name>
      <role-name> Notifier </role-name>
      <role-name> Director </role-name>
      <role-name> DisplayId </role-name>
      <role-name> DisplayName </role-name>
     </security-role>
    </assembly-description>
  • Once the security roles are defined, the application deployer then associates each role with a set of methods.
  • Referring to FIG. 2, how roles are defined as a set of method permissions is illustratively shown. As can be seen in FIG. 2, roles may include, e.g., a Notifier, a Manager, a Director, DisplayID and DisplayName. For example, the Notifier role has the permission to invoke the method setData defined in the Subject class.
  • In J2EE™ roles are typically defined for enterprise Java™ beans (EJB) components rather than arbitrary classes. For simplicity, examples of general Java™ classes will be employed, instead of EJB examples. For the example shown in FIG. 2, a principal with the Notifier role is permitted to access (that is, invoke) the method setData that is defined in the class Subject. Similarly, a principal with the DisplayId role is permitted to access all the methods (denoted by the “*” operator) that are defined in the class ObsId.
  • In J2EE™ one can use such access control specifications for other Web resources such as access to a HTTP method on a URI (Universal Resource Identifier). Also, methods that are not part of any role, are permitted to be accessed by any principal.
  • Consider a principal “Mark” who is authorized with the role DisplayId. It may be assumed that an authentication mechanism similar to a J2EE™ authentication mechanism may be employed as in known in the art. Further, assume that Mark invokes a method Driver.main. Since this method is not part of any role, an access control manager does not prevent Mark from executing the method. Now when “Mark” attempts to invoke Subject.addObs (indirectly through Drive.main), a security exception will be thrown since Mark does not have either the Director role or the Manager role. At this point, an application deployer may assign the Director role to Mark so as to avoid an access control exception, which in turn may violate the principle of least privilege. Essentially this means that to associate a role r to a method m, an application deployer has to understand the set of methods S that can be directly or indirectly invoked by m.
  • understanding such control flow is not a trivial task, especially by an application deployer. In the J2EE™ security model as known to those skilled in the art, one can also delegate permissions by associating the <run-as> tag to a class C in the deployment descriptor. The effect of such an association is to grant the permission of C to all methods that can be directly or indirectly invoked from C. A careless run-as delegation can introduce some interesting and unforeseen permission problems.
  • One main problem with role based access control (RBAC) in J2EE™ is that roles are defined for controlling access to methods and not for explicitly controlling access to data. In other words, there is no explicit mechanism for controlling access to data fields and object instances.
  • Access control to data and objects has to be performed implicitly by giving access to methods which in turn accesses the data. An important security implication of such access control through methods is that information could potentially be leaked through data flow across methods.
  • Referring again to the example in FIG. 1, using pointer analysis, one can determine that the object referenced in statement 43: is accessed by more than one method (e.g., Subject.notifyObs, Subject.addObs, and ObsId.update). Unless the roles are assigned correctly or consistently among these methods, there could be potential access control and information flow security problems.
  • Referring again to FIG. 2, the method ObsName.update and the method Obsid.update are part of two different roles. Therefore, when obs.update( ) is invoked at statement 43:, the target method could be either ObsId.update or ObsName.update depending on the runtime type of obs. Since, ObsName.update and ObsId.update have two different roles, there could be a potential security problem when the method is dispatched. Therefore, it is important to ensure that both methods are assigned the same role. The security problems that arise are either: (1) too many permissions are given to a principal, which in turn may violate the principle of least privilege, or (2) inadequate permissions are given, which can lead to unnecessary access control exceptions. There can be subtle security violations, such as information tainting and information leakage, when the principle of least privilege is compromised. Note that a simple propagation of roles over the call graph of the program is not sufficient to detect such data flow security problems.
  • Aspects of the present embodiments focus on data-centric security by introducing two concepts: (1) Role Analysis and (2) Consistency-Based Security and Role Typestates.
  • (1) Role Analysis: A simple interprocedural static analysis for detecting security problems that may arise when objects are accessed by multiple methods that do not have compatible or consistent assignment of roles to methods is provided. The notion of an object “escaping” a role is presented and a simple interprocedural static analysis for computing the set of objects that may escape a role is described.
  • (2) Consistency-Based Security and Role Typestates: Method-based role assignments are extended to consistency-based role assignments and roles are assigned to typestates rather than methods. The typestate description of a class is a configuration of its fields, and essentially abstract consistency properties of the fields.
  • RBAC Models and Program Representation: Static analysis is a process for determining the relevant properties of a program without actually executing the program. A program includes a collection of methods or procedures and is represented using a call graph (CG). A CG G=(N, E) is a directed graph, where N is a set of nodes and E is a set of edges. The set of nodes N is partitioned into two disjoint sets: (1) Nc is a set of call site nodes and (2) Nm is a set of method nodes. The set of edges E is also partitioned into two disjoint sets: (1) Em,c is a set of edges from a method node xm to each call site node xc defined in the method, and (2) Ec,m is a set of edges from a call site node xc to each method node xm that can possibly be invoked from the call site xc. A path is a sequence of edges starting from some node in the call graph. If there is a path from a method node xm to another method node ym then the method corresponding to xm may directly or indirectly invoke the method corresponding to ym.
  • Referring to FIG. 3, a call graph 200 is illustratively shown for the example program of FIG. 1, where numbers in FIG. 3 correspond to statement numbers in FIG. 1. Pointer analysis includes computing points-to information, represented as a pointer graph, at relevant program points. A pointer graph includes a set of nodes representing compile-time objects and pointer references. For heap allocated objects, pointer p can point-to an object O if p can include the address of 0. Typically, the address of O is not known at compile-time and one then assigns compile-time labels to heap objects. There are several different kinds of pointer analyses depending on precision and cost of the analysis. Typically, flow insensitive and context insensitive analysis tends to be cheaper, but less precise than flow sensitive and context sensitive analysis.
  • Referring to FIG. 4, a pointer graph is illustrated that is computed using a flow insensitive pointer analysis for the code of FIG. 1, where non-bracketed numbers in FIG. 4 correspond to statement numbers in FIG. 1. The notation p→O may be employed to denote that p points-to O. It will also be assumed that objects have fields and each field has a name that can be accessed from the object type or class. Dot-notation is used to access fields, e.g., p.f or O.f , and it can be stated that: p.f→O to denote that p points to some object O1 and the field f of O1 points to another object O.
  • Role Modeling: J2EE™ security is defined in terms of: (1) principals or authenticated users, (2) roles that define named job functions, and (3) permissions that map a role to a set of operations or methods defined in one or more classes. In J2EE™, roles are often defined for Enterprise JavaBeans (EJBs), and for simplicity, herein, Java™ classes will be employed instead of EJBs. For instance, consider the Subject class that includes the methods setData, addObs, removeObs, and notifyObs. A role such as Notifier (see FIG. 2) is given permission to invoke setData. On the other hand, a role such as Director is given permission to invoke all four operations. Notice that a principal with a Director role can invoke any operation that a principal with a Manager role or a Notifier role can invoke. In other words, Director is considered to be “senior” to Manager and Notifier.
  • Let C denote a set of classes for which RBAC is provided, and let M denote a set of methods in C. A permission Per is a mapping from role r in R to a subset of methods in M. Now, let Per(r) denote the set of method permissions assigned to a role r. For example, Per(Manager)={Subject.addObs Subject.removeObs}.
  • Definition [Senior Roles]. Let r and s be any two roles in R. r is a senior role of s, denoted as r>s, if Per(r) Per(s).
  • Conversely, a junior role may be defined as follows. r<s, if Per(r) Per(s).
  • Next, a role graph is defined in which nodes represent roles and edges represent the senior (junior) relations. The role graph form employed in this disclosure will include a lattice structure, with τ representing a role that is the union of all method permissions and ⊥ representing a role whose permission set is the empty set. A lattice is a partial order with a join and a meet for every pair of nodes. Given any two nodes x and y, the set union of x and y is the join (␣), and the set intersection of x and y is the meet (
    Figure US20070282841A1-20071206-P00001
    ).
  • Now let Peri(r) be a set of method permission that is initially assigned a role r (as specified in the deployment descriptor). In J2EE™ a method permission can be assigned to more than one role. Let Rolei(m) denote the set of roles that an application deployer initially assigns to m. In other words, Rolei(m)={r|m ε Peri(r)}. For example, Rolei(Subject.setData)={Notifier, Director}. If a method is not explicitly assigned to any role, then it can be accessed by any principal. Note that one can also use the “*” to indicate all the methods in a class as belonging to a specific role.
  • Role Analysis: Two illustrative role analyses are presented and include: (1) role consistency analysis for computing consistent role assignment and (2) role escape analysis for computing the set of objects that may escape a role.
  • Role Consistency Analysis: Let r be a role assigned to m (by an application deployer), and let m′ be a method that can be invoked directly or indirectly from m. A principal who is assigned the role r should also have permission to invoke the method m′, i.e., m′ should also be in Per(r). Often an application deployer handles only entry methods of an application or a component. These entry methods are essentially the application programming interface (API) of the application. In the case of a Java™ application, the entry methods are the set of public and protected methods defined in interfaces and classes. Therefore, an application deployer has the capability to define permission sets and assign roles based on the entry methods defined in an API.
  • Let A be an application, let Me be a set of entry methods to A (as defined in its API), and R be the set of roles defined using the entry methods.
  • Referring to FIG. 5, an application or component model is illustratively shown. Notice that an entry method such as m1 can directly or indirectly invoke another entry method m2. One question is how to define consistent roles and permission sets that are based on only the entry methods of an application. Consider an entry method m1 ε Me and let r1 ε R. Now, define r1 to include ml in its permission set, that is m1 ε Per(r1), and therefore r1 E Role(m1). What this essentially means is that if a principal P is assigned the r1, then P has the permission to invoke m1. Now let m2 be some other method reachable from m1, and so P should also have the permission to invoke m2. Let Per(r2)={m2, m3}, and so m2 ε Role(r2). r1 and r2 should be ensured to have a consistent permission set.
  • There are two cases to consider: (1) m2 is not in Per(r1), and in this case P should also be assigned the role r2 so as to avoid access control exception. On one hand, by assigning r2 to P, also give P the permission to access m3, which violates the principle of least privilege. On the other hand, m3 may be in a different sub-component, in which case separating the roles makes sense in some situations, even if the principle of least privilege is violated. (2) m2 is in Per(r1), and in this case the assignment is consistent.
  • One way to compute consistent role assignment is to first determine the set of methods that are reachable from an entry point in the call graph of the program. Let L be the set of methods that are reachable from an entry point m ε Me in the call graph. Let L′m=L ∩ Me, and so L′m is a set of methods that are reachable from m and the set of methods are also entry methods. Now let r be a role with m E Per(r). Since a method 1′ ε L′m is also reachable from m, ensure that 1′ ε Per(r). So rather than defining arbitrary roles and permission set, a deployer first computes L′m for each entry method m. The deployer can then define roles based on the entry method m and L′m by ensuring that L′m Role(m).
  • Applications may be composed of many components and the components are assigned with consistent roles. Consider the example shown in FIG. 1 and the role assignment shown in FIG. 2. Let Rolei denote the initial set of role assignments. In order for a principal to invoke Subject.setData the principal not only needs the Notifier, but also DisplayId and DisplayName roles.
  • Referring to FIG. 6, an annotated call graph is illustratively shown with Rolei and Role+, which are the initial role assignments and the minimum roles needed to invoke the methods. Computing Role+ for each method is a straightforward backward propagation of roles over the call graph and at each step only propagation of junior roles up the call graph is performed. That is, a lattice join is performed at each step and the joined role information is propagated.
  • The role analysis described previously is preferably based on reachability over a call graph of a program. Although role propagation over the call graph may be important in preventing certain kinds of access control problems, it does not detect access problems that could happen due to data flow across methods. A limitation of the J2EE™ security model is that it focuses on securing the mechanism (that is, methods) that access sensitive information or resources. For instance, J2EE™ does not allow one to specify roles for class fields and class instances. Subtle problems may arise due to data flow across methods. For example, the receiver expression (such as 43: obs.update(data) in FIG. 1 can target more than one method. Programmers have to make sure that the roles assigned to the target method are consistent with the role assigned to a method that invokes the object.
  • Also, an object is often accessed by multiple methods that have different roles assigned to them. Consider the points-to graph shown in FIG. 4, and, in particular, the object 62:ObsId. This object is directly accessed by the methods Driver.main (which created the object), ObsId.update (via the “this” parameter), and Subject.notifyObs. Now, consider the role assignment and method permission shown in FIG. 6. The method ObsId.update is assigned only to role Display. Unfortunately, since the object, 62:ObsId, is also accessed by other methods, there can be inconsistencies among roles assigned to different methods that access the same object. This can lead to information leakage.
  • Given the pointer graph of a program, for each object, the set of methods are computed that directly access the object. Call the resulting graph a method-annotated pointer graph (MAPG). It is straightforward to compute this information if fully qualified names are used for reference. Consider the pointer graph shown in FIG. 4 and the object 62:ObsId. The set of methods that access this object can be read off from the pointer graph, which is Driver.main, Subject.addobs, Subject.notify, and Obsid.update. Since any of these methods have the “capability” to access the object, the object is assigned a role that is the least upper bound of the roles assigned to these methods. Now a principal who wants to access the object referenced by 62:ObsId should have a role that is at least equal to the least upper bound of the roles assigned to the methods that access the object. Unfortunately, in J2EE™, it is not possible to assign roles to objects or class instances.
  • Role Escape Analysis: The concept of role escape analysis will now be described in accordance with present principles. Escape analysis is a procedure for determining the set of objects that escape the life time of a method or a thread. Consider the following simple example:
  • 1: void foo( ) {
    2:  LinkedList head = new LinkedList( ) ;
    3:  bar(head) ;
    4:  }
    5: void bar(LinkedList h){
    6:  LinkedList n = new LinkedList( ) ;
    7:  n.next = null ;
    8:  h.next = n ;
    9: }
  • The object 6:bar.LinkedList created at 6: escapes the method bar because there is an access path to the object from the parameter reference h. On the other hand, the object 2:foo.LinkedList created at 2: and the object 6:bar.LinkedList created at 6: do not escape foo. One simple way to compute whether an object O escapes a method M is first to construct the pointer graph and then check if there is a path to O in the graph that can be reached by some node O′ that is accessed in some other method M′ and the life time of M′ that exceeds the life time of M.
  • In role escape analysis, the method escape analysis may be extended as follows. An object O role escapes a method M with role R if there is a path in the pointer graph from some node O′ that is accessed in some other method M′ with role R′ and R κ R′. Conversely, an object O is role confined to a M if O does not role escape M. A definition of role escape employed herein is more general than the traditional method or thread escape, whereby method lifetime is defined herein as a role. The role escape analysis essentially includes determining if a node p in the pointer graph that is annotated with method m and role r ε Role+ (m) is reachable from another node p′ that is annotated with m′ and role r′ ε Role+ (m′) and r κ r′.
  • Notice that the converse of role escape, which is role confinement, of an object is closely related to information flow security. Since roles are modeled using a lattice structure, if an object O does not escape a role R then the object cannot leak information outside the role. Also, if an object escapes a role, the object can become “tainted” by an external principal with access to the object.
  • Consistency-Based Security: It is often the case that an application developer has a better understanding of the application that he or she is developing than an application deployer or the system administrator. On the other hand an application deployer has a better understanding of the application deployment environment than an application developer. One idea behind consistency-based security (CBS) is to focus on the consistency properties of data and methods. An application developer simply identifies and defines the consistency properties as code annotation. A simple consistency property could be that two fields of a Java™ class are modified by the same set of methods. Another consistency property is the typestate property, which is often used to specify ordering of methods in an application. In CBS, a tool can scan the code and present the developer's consistency properties to an application deployer. An application deployer can then use the consistency properties as a guide for associating security properties to roles, and then grant authorization to users.
  • Data Consistency Security: a simple consistency property in which two or more fields of an object are all accessed by the same set of methods. Given this property, an application deployer can then associate the same role for all methods that access these fields. Consider a simple employee record in a company.
  • EMPLOYEE RECORD:
  • enum EmpType = {RSM, Manager, SoftEng, Staff} ;
    class Employee {
      String fname ; // first name
      String lname ; // last name ;
      int id ; // company identity number
      int ssn ; // social security number
      String gender ;
      String ethnic ; // ethnicity
      EmpType etype ;
    }
  • Suppose an application developer is developing a business application, such as a payroll application, and decides that gender, and ethnicity (“ethnic”) have the same “consistency property. A simple example of a consistency property is that the two fields are always accessed by the same set of methods. Another example of a consistency property is access rights; if a user is permitted to access one of the two data fields, then the user is automatically allowed to access the other data field. Yet another example of a consistency property is encryption; the values of the two data fields should use the same encryption/decryption keys. An application developer usually has a better understanding of the consistency properties than the application deployer. For instance, if gender, and ethnic are always accessed by the same set of methods, the developer can then define a simple consistency property classification called race.
  • CONSISTENCY PROPERTY CLASSIFICATION—RACE:
  • class Employee {
      access(name, idy) String fname ;
      access(name, idy) String lname ;
      access(idy) int id ;
      access(idy) int ssn ;
      access(race) String gender ;
      access(race) String ethnic ;
    }
  • Often a field (or a method) can belong to more than one class of a consistency property. For instance, fname (first name) and lname (last name) belong to two different classes of the access property. A consistency property includes two parts: (1) a property name such as access and (2) a set of classifications, such as name, idy, and race. Given the consistency properties defined by an application developer, a natural question to ask is how will the application deployer use them. An application deployer first queries the application for all application-defined properties. Next, the application deployer associates roles to consistency properties. Suppose an application deployer defines two roles called Manager and NonManager, and associates the Manager role with access(name,idy,race) and NonManager role with access(name). With this association, a Manager can access all the defined fields, whereas a NonManager can only access the fields fname and lname. Notice that a deployer does not need to understand how a developer defined the consistency properties. The deployer only has to know what set of consistency properties have been defined by the developer.
  • Role Typestates: RBAC's are defined by focusing on the typestate consistency property. The approach that may be employed is very simple: an application developer defines the typestate properties and an application deployer then assigns roles based on the typestate properties. Typestates provide much richer information than simple method interfaces to an application deployer.
  • The concept of a typestate may be understood as an extension to the notion of a type by providing that a variable be in a certain state before operations on the variable can be performed. In other words, certain preconditions have to be met prior to performing any operation on a variable. Typestate is useful for tracking certain kinds of flow-sensitive errors or bugs, such as uninitialized variables. For object-oriented (00) programs, the typestate of an object (that is, an instance of a class) is a description or a configuration of all its fields. In OO programs, a method that is invoked on an object o typically has a partial view of the object o. One can use typestates to define a consistent view of an object prior to an invocation of a method on the object. Consider a simple file object that includes two typestates Open and Close.
  • FILE OBJECT WITH TWO TYPESTATES:
  •  class File {
    typestate = Start, Open, Close
    // @requires Start
    File create(String fname) ; // create file
    // @requires Close
    void open( ) //
    // @requires Open
    String read( ) ; // returns the content of file
    // @requires Open
    void write(String data) ; // write to file
    // requires Open
    void close( ) ; // close the file
    }
  • Referring to FIG. 7, a typestate diagram is a finite state diagram, with nodes denoting the typestates of a class (e.g., open and close) and a labeled edges denoting transitions between typestates of a class. The labels on the edges (e.g., close( ), open( ), create( ), read( ), write( ) ) correspond to (a subset of) methods defined in the class. The source and destination nodes of a transition correspond to pre- and post-conditions of the method that labels the transition, respectively. An execution of a method takes an instance of a class from one typestate to another typestate. FIG. 7 illustrates a typestate diagram for the File class code (FILE OBJECT WITH TWO TYPESTATES) presented earlier. The typestate diagram specifies the life-cycle of how an instance of the File class goes between Open and Close typestates. A method, such as open( ), is executed only when its pre-condition typestate of the File object is Close, and after the execution the new typestate of the object is Open. Both read( ) and write( ) methods can execute only when the File object is in Open state.
  • The typestate diagram is an external specification of a class. It prescribes the order in which a client can invoke various methods defined in the class. Generally, only an application developer understands the lifecycle of an object. Given such a specification, an application deployer can now associate security properties to typestates. For instance, an application deployer can associate Manager role to Start, Open and Close typestates, and Engineer role to Open. What this essentially means is that only a Manager is permitted to execute all methods of the class, whereas an Engineer is permitted to execute only read( ) and write( ) methods.
  • In accordance with present principles, a typestate diagram may be partitioned into a hierarchical structure and use the notion of a hierarchical typestate diagram. A hierarchical typestate diagram includes a set of states and a set of transitions. A state may be composed of other states, called sub-states. This enables modeling of a complex hierarchical typestate diagram by abstracting away detailed behavior into multiple levels. States that do not include sub-states are called simple states, whereas states that have sub-states are called composite states. States may be nested to any level. A transition relates two states: a source state and a destination state. Transitions are labeled and each label corresponds to a method invocation. An invocation of a method can cause a state transition. The hierarchical states in a typestate diagram may induce a tree structure. FIG. 8 illustrates a hierarchical typestate diagram in which the Open state shown in FIG. 7 has been expanded. For role typestates, it is natural to model roles using a tree structure.
  • Referring to FIG. 9, a tree structure 120 having role assignments models is illustratively shown. Roles R0-R4 are assigned to each method in the tree. The definition of senior relation is simpler: r>s if r is a parent of s in the role hierarchy tree 120. Roles are assigned to hierarchical states in the typestate diagram. If s is assigned the role r then the Per(r)={t|t ε Root(s)}, where Root(s) is a set of all states in the sub-tree that is rooted at s in the typestate hierarchy tree 120.
  • Consider the role assignment shown in FIG. 9, and the permission set for each role includes:
    • Per(R0)={File,Open,Close,OpenRead,OpenWrite},
    • Per(R1)={Open,OpenRead,OpenWrite},
    • Per(R2)={Close},
    • Per(R3)={OpenRead}, and
    • Per(R4)={OpenWrite}.
  • If a principal P is assigned the role R1 then P can invoke both read and write, but cannot invoke close. Now if P is assigned R3 then P can only invoke the read method.
  • Consider a method such as File.close( ) and a principal P who is assigned the role R1. The principal P should not be allowed to invoke File.close( ) even if the current typestate of the object referenced by the principal is Open. This is because, the method File.close( ) creates a state transition from Open to Close and P is not allowed to be in state Close. So only principals with role File are essentially permitted to execute File.close( ).
  • Given a set of roles assigned to typestates, the roles needed for methods can easily be computed as the least common ancestor of the roles assigned to the pre- and post-state of the method. Note that when a File object is passed around to different methods that are accessed by different principals, we only have to ensure that roles are consistent on the current typestate of the object and do not have to worry about the methods themselves.
  • Typestates are useful for modeling access patterns, including message patterns in, e.g., Web Services. Once such message patterns are modeled using typestates, roles can be assigned to states using the present principles and provide security for applications, e.g., Web Service applications.
  • The present embodiments address the challenges of role assignment and role semantics in building applications. The prior art method-based access control is limiting in terms of its expressive power. In accordance with one embodiment, a data-centric security is employed to complement the method-based security. Role-based access control for managing and controlling access to sensitive resources is provided. RBAC models have become popular because of their generality in expressing a diverse set of access control policies. Security analysis techniques are provided for ensuring that security properties are correctly maintained even in the presence of delegating administrative privileges.
  • A simpler lattice structure for modeling roles is also employed. The notion of role escape analysis is introduced to specially address the need for data-centric security. Also presented is consistency-based security, along with role typestates for specifying access control security.
  • The role analysis described herein is related to static analysis. The consistency-based security and role typestate is one preferred way to extend the J2EE™ model to deal with data-centric security.
  • Java 2 Standard Edition™ (J2SE™) provides security mechanisms for protecting resources (e.g., the file system) in terms of run-time stack inspection. The security access control model is based on properties that include code origin and principal's execution environment. The present disclosure follows program analysis techniques for RBAC, uses typestate properties for RBAC, and introduces the notion of role escape analysis and the notion of role typestates to model and detect security problems, e.g., in J2EE™.
  • In accordance with present principles, role escape analysis generalizes the traditional escape analysis, where the method and thread lifetime are considered to be an instance of roles. Role escape analysis is useful for detecting confinement properties of objects, and for detecting information leaks through objects.
  • Role typestates combine the notion of roles and typestates. By associating roles to typestates, a more general model is defined for specifying roles; instead of specifying roles on methods, the role are now specified on typestates.
  • The present disclosure describes some of the security issues related to J2EE™ RBAC model, illustrated several examples that show the limitation of method-based role assignment, and discussed the concepts that bring out a data-centric security model. Consistency based security that includes typestate security may be employed to complement method-based security. In other words, the present principles may be employed in addition to or instead of the security measures employed in the prior art environments.
  • Referring to FIG. 10, a block/flow diagram showing a system/method for providing access control using roles is illustratively depicted. In block 202, for at least one typestate, typestate properties are determined or provided. In one example, typestate properties include an association of a security property (or level) with the typestate to assign the role to the typestate.
  • In block 204, a role is assigned to the at least one typestate in a program in accordance with the typestate properties. In block 206, a typestate hierarchy tree may be generated and roles are assigned to nodes of the hierarchy tree where the nodes represent the typestates.
  • In block 210, access to operations of the at least one typestate in the program are limited based on the role assigned to the at least one typestate and an access permission level. Limiting access may include denying access to the at least one typestate if a role is junior to an assigned role and/or permitting access to the at least one typestate if a role is senior to an assigned role.
  • In block 212, a role consistency analysis may be performed to determine if assigning the role is consistent throughout the program. In block 214, a role escape analysis may be performed to determine if any program objects escape a role assignment. In block 216, a method-based access control method may be employed instead of or in addition to the present method for access control.
  • Referring to FIG. 11, a block/flow diagram showing a system/method for analyzing role consistency for program access control is illustratively depicted. In block 302, for each object in a program having a plurality of objects, a set of methods that directly access an object is computed. This may include generating a pointer graph of the program, such as, a method-annotated pointer graph.
  • A role assignment is checked for each object by determining if the object's role is a least upper bound of the roles assigned to the methods of the set in block 304. Access is permitted to the set of methods if an accessor's role is at least equal to the least upper bound of the roles assigned to the methods that access the object in block 308.
  • A role escape analysis (blocks 320-324) may be performed instead of or in addition to the role consistency analysis (blocks 302-308) to determine if any program objects escape a role assignment. The role escape analysis includes constructing a pointer graph for a program having a plurality of objects having assigned roles in block 320. In block 322, each object O is checked to determine if 0 role escapes a role R by determining if there exists another path to that object O in the pointer graph that can be reached by some node O′ that is accessed in another role R′ and a lifetime of the method R′ exceeds the life time of R. In block 324, it is determined whether information is leaked or contained based upon role escaped objects or lack thereof. The role consistency analysis may be performed separately or in addition to the role escape analysis.
  • Referring to FIG. 12, an illustrative system 400 includes a program access control program or module 402 capable of supporting role-based security and role-based security compliance in accordance with the present principles. Program 402 is preferably incorporated into the operating system of computers, nodes and servers where access control is needed. In one embodiment, each operating system for all devices employed in the system 400 employs the role-based system of the present invention. System 400 may include a private computer network, a single computer (409) or a public computer network, such as the Internet or any combination of these. In addition, the role-based access control may be employed in telephones (cell phones), handheld or laptop computers (e.g., PDAs), or any other computing device or system.
  • Server 401, computer 409 and each computer or node 404 in the network may include memory storage 403 (e.g., RAM) where an operating system 405 in conjunction with a processor 407 and communication protocols are employed to facilitate communications between network or computer users and perform the action needed for access control in accordance with present principles. Nodes or computers 404 may include access points for a plurality of users to a server 401 or may include individual computers which grant or deny permission to gain access to methods 406 and/or typestates 408 stored on a computer or server 401. Although methods 406 and typestates 408 are shown in the server 401 and computer 409, any or all computers 404 in the network or independent computers 409 may include methods and typestates that are under access control. The methods and typestates include roles such that a principal attempting to access the method and/or the typestate can gain access to the method or typestate only if the proper permission or access level in afforded to that principal. By employing typestates and other principles disclosed herein, method-based access control is extended by moving to a more data-centric access control system.
  • Program 402 may be distributed over the network or located on a server; however, program or module 402 is preferably included in the operating system of individual computers or servers. Program 402 further includes features to provide for role assignment, check for role consistency and determine whether any roles assigned can be escaped as described above in accordance with present principles.
  • Having described preferred embodiments of a system and method for role based analysis and access control (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments disclosed which are within the scope and spirit of the invention as outlined by the appended claims. Having thus described aspects of the invention, with the details and particularity required by the patent laws, what is claimed and desired protected by Letters Patent is set forth in the appended claims.

Claims (20)

1. A method for program access control, comprising:
for at least one typestate, providing typestate properties;
assigning a role to the at least one typestate in a program in accordance with the typestate properties; and
limiting access to operations of the at least one typestate in the program based on the role assigned to the at least one typestate and an access permission level.
2. The method as recited in claim 1, further comprising generating a typestate hierarchy tree and assigning roles to nodes of the hierarchy tree wherein the nodes represent typestates.
3. The method as recited in claim 1, wherein providing typestate properties includes associating a security property with the typestate to assign the role to the typestate.
4. The method as recited in claim 1, further comprising performing a role consistency analysis to determine if assigning the role is consistent throughout the program.
5. The method as recited in claim 1, further comprising performing a role escape analysis to determine if any program objects escape a role assignment.
6. The method as recited in claim 1, wherein limiting access to operations includes denying access to the at least one typestate if a role is junior to an assigned role.
7. The method as recited in claim 1, wherein limiting access to operations includes permitting access to the at least one typestate if a role is senior to an assigned role.
8. The method as recited in claim 1, wherein the method is included with and extends a method-based access control method.
9. A method for analyzing role consistency for program access control, comprising:
computing, for each object in a program having a plurality of objects, a set of methods that directly access an object;
checking a role assignment for the object by determining if the object's role is a least upper bound of the roles assigned to the methods of the set; and
permitting access to the set of methods if an accessor's role is at least equal to the least upper bound of the roles assigned to the methods that access the object.
10. The method as recited in claim 9, wherein computing includes generating a pointer graph of the program.
11. The method as recited in claim 10, wherein pointer graph includes a method-annotated pointer graph.
12. The method as recited in claim 9, further comprising performing a role escape analysis to determine if any program objects escape a role assignment.
13. A computer program product comprising a computer useable medium having a computer readable program, wherein the computer readable program when executed on a computer causes the computer to analyze role consistency for program access control as recited in claim 9.
14. A method for analyzing role consistency for program access control, comprising:
constructing a pointer graph for a program having a plurality of objects having assigned roles;
checking each object O to determine if O role escapes a role R by determining if there exists another path to that object O in the pointer graph that can be reached by some node O′ that is accessed in another role R′ and a lifetime of the method R′ exceeds the life time of R; and
determining that information is leaked based upon role escaped objects.
15. The method as recited in claim 14, further comprising performing a role consistency analysis to determine if assigning the role is consistent throughout the program.
16. A computer program product comprising a computer useable medium having a computer readable program, wherein the computer readable program when executed on a computer causes the computer to analyze role consistency for program access control as recited in claim 14.
17. A computer program product comprising a computer useable medium having a computer readable program for program access control, wherein the computer readable program when executed on a computer causes the computer to perform the steps of:
for at least one typestate, providing typestate properties;
assigning a role to the at least one typestate in a program in accordance with the typestate properties; and
limiting access to operations of the at least one typestate in the program based on the role assigned to the at least one typestate and an access permission level.
18. The computer program product as recited in claim 17, further comprising performing a role consistency analysis to determine if assigning the role is consistent throughout the program.
19. The computer program product as recited in claim 17, further comprising performing a role escape analysis to determine if any program objects escape a role assignment.
20. The computer program product as recited in claim 17, wherein limiting access to operations includes at least one of denying access to the at least one typestate if a role is junior to an assigned role and permitting access to the at least one typestate if a role is senior to an assigned role.
US11/446,104 2006-06-01 2006-06-01 System and method for role based analysis and access control Expired - Fee Related US7933925B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US11/446,104 US7933925B2 (en) 2006-06-01 2006-06-01 System and method for role based analysis and access control
US12/196,682 US8543607B2 (en) 2006-06-01 2008-08-22 System and method for role based analysis and access control
US13/668,918 US20130067592A1 (en) 2006-06-01 2012-11-05 System and method for role based analysis and access control
US13/966,574 US9785799B2 (en) 2006-06-01 2013-08-14 System and method for role based analysis and access control

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/446,104 US7933925B2 (en) 2006-06-01 2006-06-01 System and method for role based analysis and access control

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/196,682 Continuation US8543607B2 (en) 2006-06-01 2008-08-22 System and method for role based analysis and access control

Publications (2)

Publication Number Publication Date
US20070282841A1 true US20070282841A1 (en) 2007-12-06
US7933925B2 US7933925B2 (en) 2011-04-26

Family

ID=38791582

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/446,104 Expired - Fee Related US7933925B2 (en) 2006-06-01 2006-06-01 System and method for role based analysis and access control
US12/196,682 Expired - Fee Related US8543607B2 (en) 2006-06-01 2008-08-22 System and method for role based analysis and access control
US13/668,918 Abandoned US20130067592A1 (en) 2006-06-01 2012-11-05 System and method for role based analysis and access control
US13/966,574 Active 2027-09-09 US9785799B2 (en) 2006-06-01 2013-08-14 System and method for role based analysis and access control

Family Applications After (3)

Application Number Title Priority Date Filing Date
US12/196,682 Expired - Fee Related US8543607B2 (en) 2006-06-01 2008-08-22 System and method for role based analysis and access control
US13/668,918 Abandoned US20130067592A1 (en) 2006-06-01 2012-11-05 System and method for role based analysis and access control
US13/966,574 Active 2027-09-09 US9785799B2 (en) 2006-06-01 2013-08-14 System and method for role based analysis and access control

Country Status (1)

Country Link
US (4) US7933925B2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080022370A1 (en) * 2006-07-21 2008-01-24 International Business Corporation System and method for role based access control in a content management system
US20080313613A1 (en) * 2007-03-21 2008-12-18 Bierhoff Kevin M Method for statically checking an object-oriented computer program module
EP2372594A1 (en) * 2010-03-19 2011-10-05 Sap Ag Security sensitive data flow analysis
US20140215603A1 (en) * 2013-01-31 2014-07-31 International Business Machines Corporation Automated role adjustment in a computer system
CN109697036A (en) * 2018-12-29 2019-04-30 北京金山安全软件有限公司 Information processing method and device
US20200007550A1 (en) * 2018-06-29 2020-01-02 Sap Se Authorization client management in a distributed computing environment
US10540255B2 (en) * 2017-10-31 2020-01-21 Oracle International Corporation Staged refinement for static analysis
US10554667B2 (en) 2015-01-22 2020-02-04 Alibaba Group Holding Limited Methods, apparatus, and systems for resource access permission management
WO2022066414A1 (en) * 2020-09-23 2022-03-31 Amazon Technologies, Inc. Compositional reasoning techniques for role reachability analyses in identity systems
US20220222365A1 (en) * 2017-01-10 2022-07-14 Snowflake Inc. Data sharing using alias objects

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080184208A1 (en) * 2007-01-30 2008-07-31 Sreedhar Vugranam C Method and apparatus for detecting vulnerabilities and bugs in software applications
US8230477B2 (en) * 2007-02-21 2012-07-24 International Business Machines Corporation System and method for the automatic evaluation of existing security policies and automatic creation of new security policies
US8332939B2 (en) * 2007-02-21 2012-12-11 International Business Machines Corporation System and method for the automatic identification of subject-executed code and subject-granted access rights
DE102008019103A1 (en) * 2008-04-16 2009-10-22 Siemens Aktiengesellschaft Method and device for transcoding in an encryption-based access control to a database
GB2459682B (en) * 2008-04-30 2012-04-25 Vmware Inc A computer system and a method of deploying an application in a computer system
US10447334B2 (en) 2008-07-09 2019-10-15 Secureall Corporation Methods and systems for comprehensive security-lockdown
US10128893B2 (en) 2008-07-09 2018-11-13 Secureall Corporation Method and system for planar, multi-function, multi-power sourced, long battery life radio communication appliance
US11469789B2 (en) 2008-07-09 2022-10-11 Secureall Corporation Methods and systems for comprehensive security-lockdown
US9642089B2 (en) 2008-07-09 2017-05-02 Secureall Corporation Method and system for planar, multi-function, multi-power sourced, long battery life radio communication appliance
US9275246B2 (en) * 2009-10-08 2016-03-01 International Business Machines Corporation System and method for static detection and categorization of information-flow downgraders
US8745397B2 (en) 2010-01-04 2014-06-03 Microsoft Corporation Monitoring federation for cloud based services and applications
US8949812B2 (en) * 2010-08-30 2015-02-03 International Business Machines Corporation System and method for updating hard-coded dependencies
US9165156B2 (en) 2012-12-03 2015-10-20 Microsoft Technology Licensing, Llc Role-based access control modeling and auditing system
US9495380B2 (en) 2012-12-20 2016-11-15 Bank Of America Corporation Access reviews at IAM system implementing IAM data model
US9189644B2 (en) 2012-12-20 2015-11-17 Bank Of America Corporation Access requests at IAM system implementing IAM data model
US9529629B2 (en) 2012-12-20 2016-12-27 Bank Of America Corporation Computing resource inventory system
US9542433B2 (en) 2012-12-20 2017-01-10 Bank Of America Corporation Quality assurance checks of access rights in a computing system
US9489390B2 (en) 2012-12-20 2016-11-08 Bank Of America Corporation Reconciling access rights at IAM system implementing IAM data model
US9537892B2 (en) 2012-12-20 2017-01-03 Bank Of America Corporation Facilitating separation-of-duties when provisioning access rights in a computing system
US9483488B2 (en) 2012-12-20 2016-11-01 Bank Of America Corporation Verifying separation-of-duties at IAM system implementing IAM data model
US9477838B2 (en) 2012-12-20 2016-10-25 Bank Of America Corporation Reconciliation of access rights in a computing system
US9239873B2 (en) * 2013-06-25 2016-01-19 International Business Machines Corporation Process-aware code migration
US9147055B2 (en) 2013-08-29 2015-09-29 Bank Of America Corporation Entitlement predictions
CN104484617B (en) * 2014-12-05 2017-09-26 中国航空工业集团公司第六三一研究所 A kind of Access and control strategy of database method based on many strategy fusions
CN105550590A (en) * 2015-09-09 2016-05-04 上海赞越软件服务中心 Role-based access control mechanism
CN107480537A (en) * 2017-06-28 2017-12-15 北京小度信息科技有限公司 Authority the Resources list automatic generation method and device
US11741196B2 (en) 2018-11-15 2023-08-29 The Research Foundation For The State University Of New York Detecting and preventing exploits of software vulnerability using instruction tags
US11803429B2 (en) 2020-10-30 2023-10-31 Red Hat, Inc. Managing alert messages for applications and access permissions

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5347578A (en) * 1992-03-17 1994-09-13 International Computers Limited Computer system security
US5581691A (en) * 1992-02-04 1996-12-03 Digital Equipment Corporation Work flow management system and method
US5634127A (en) * 1994-11-30 1997-05-27 International Business Machines Corporation Methods and apparatus for implementing a message driven processor in a client-server environment
US5911143A (en) * 1994-08-15 1999-06-08 International Business Machines Corporation Method and system for advanced role-based access control in distributed and centralized computer systems
US6088679A (en) * 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US6938186B2 (en) * 2002-05-28 2005-08-30 Microsoft Corporation System and method for performing a path-sensitive verification on a program
US6950825B2 (en) * 2002-05-30 2005-09-27 International Business Machines Corporation Fine grained role-based access to system resources
US20050262132A1 (en) * 2004-05-21 2005-11-24 Nec Corporation Access control system, access control method, and access control program
US20060059567A1 (en) * 2004-02-20 2006-03-16 International Business Machines Corporation System and method for controlling data access using security label components
US20070074188A1 (en) * 2005-05-16 2007-03-29 Yao-Wen Huang Systems and methods for securing Web application code
US7350237B2 (en) * 2003-08-18 2008-03-25 Sap Ag Managing access control information

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023765A (en) * 1996-12-06 2000-02-08 The United States Of America As Represented By The Secretary Of Commerce Implementation of role-based access control in multi-level secure systems
US6202066B1 (en) * 1997-11-19 2001-03-13 The United States Of America As Represented By The Secretary Of Commerce Implementation of role/group permission association using object access type
WO2000026750A1 (en) * 1998-11-05 2000-05-11 NEUVIS, Inc Method for controlling access to information
US6985953B1 (en) * 1998-11-30 2006-01-10 George Mason University System and apparatus for storage and transfer of secure data on web
US20020026592A1 (en) * 2000-06-16 2002-02-28 Vdg, Inc. Method for automatic permission management in role-based access control systems
US7124192B2 (en) * 2001-08-30 2006-10-17 International Business Machines Corporation Role-permission model for security policy administration and enforcement
US6826716B2 (en) * 2001-09-26 2004-11-30 International Business Machines Corporation Test programs for enterprise web applications
US7076798B2 (en) * 2002-02-07 2006-07-11 International Business Machines Corporation Securing non-EJB corba objects using an EJB security mechanism
US20040098594A1 (en) * 2002-11-14 2004-05-20 Fleming Richard Hugh System and method for creating role-based access profiles
US6917975B2 (en) * 2003-02-14 2005-07-12 Bea Systems, Inc. Method for role and resource policy management
US7568217B1 (en) * 2003-03-20 2009-07-28 Cisco Technology, Inc. Method and apparatus for using a role based access control system on a network
US7461395B2 (en) * 2003-05-06 2008-12-02 Oracle International Corporation Distributed capability-based authorization architecture using roles
US20050138031A1 (en) * 2003-12-05 2005-06-23 Wefers Wolfgang M. Systems and methods for assigning task-oriented roles to users
US7640429B2 (en) * 2004-02-26 2009-12-29 The Boeing Company Cryptographically enforced, multiple-role, policy-enabled object dissemination control mechanism
US20050262487A1 (en) * 2004-05-11 2005-11-24 International Business Machines Corporation System, apparatus, and method for identifying authorization requirements in component-based systems
US7882544B2 (en) * 2004-07-12 2011-02-01 International Business Machines Corporation Inherited role-based access control system, method and program product
US7600117B2 (en) * 2004-09-29 2009-10-06 Panasonic Corporation Mandatory access control scheme with active objects
US9032076B2 (en) * 2004-10-22 2015-05-12 International Business Machines Corporation Role-based access control system, method and computer program product
US7774827B2 (en) * 2005-06-06 2010-08-10 Novell, Inc. Techniques for providing role-based security with instance-level granularity
ATE520088T1 (en) * 2006-09-04 2011-08-15 Extreme Technologies Ltd METHOD FOR MANAGING CONCURRENT MODIFICATION OF DATABASE OBJECTS DURING DEVELOPMENT
US8452873B2 (en) * 2006-11-01 2013-05-28 International Business Machines Corporation Provisioning of resources in a computer network
US8132231B2 (en) * 2007-12-06 2012-03-06 International Business Machines Corporation Managing user access entitlements to information technology resources

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5581691A (en) * 1992-02-04 1996-12-03 Digital Equipment Corporation Work flow management system and method
US5347578A (en) * 1992-03-17 1994-09-13 International Computers Limited Computer system security
US5911143A (en) * 1994-08-15 1999-06-08 International Business Machines Corporation Method and system for advanced role-based access control in distributed and centralized computer systems
US5634127A (en) * 1994-11-30 1997-05-27 International Business Machines Corporation Methods and apparatus for implementing a message driven processor in a client-server environment
US6088679A (en) * 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US6938186B2 (en) * 2002-05-28 2005-08-30 Microsoft Corporation System and method for performing a path-sensitive verification on a program
US6950825B2 (en) * 2002-05-30 2005-09-27 International Business Machines Corporation Fine grained role-based access to system resources
US7350237B2 (en) * 2003-08-18 2008-03-25 Sap Ag Managing access control information
US20060059567A1 (en) * 2004-02-20 2006-03-16 International Business Machines Corporation System and method for controlling data access using security label components
US20050262132A1 (en) * 2004-05-21 2005-11-24 Nec Corporation Access control system, access control method, and access control program
US20070074188A1 (en) * 2005-05-16 2007-03-29 Yao-Wen Huang Systems and methods for securing Web application code

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080022370A1 (en) * 2006-07-21 2008-01-24 International Business Corporation System and method for role based access control in a content management system
US9455990B2 (en) * 2006-07-21 2016-09-27 International Business Machines Corporation System and method for role based access control in a content management system
US20080313613A1 (en) * 2007-03-21 2008-12-18 Bierhoff Kevin M Method for statically checking an object-oriented computer program module
US8327327B2 (en) * 2007-03-21 2012-12-04 Carnegie Mellon University Method for statically checking an object-oriented computer program module
EP2372594A1 (en) * 2010-03-19 2011-10-05 Sap Ag Security sensitive data flow analysis
US20140215603A1 (en) * 2013-01-31 2014-07-31 International Business Machines Corporation Automated role adjustment in a computer system
US8863276B2 (en) * 2013-01-31 2014-10-14 International Business Machines Corporation Automated role adjustment in a computer system
US9087148B2 (en) 2013-01-31 2015-07-21 International Business Machines Corporation Automated role adjustment in a computer system
US10554667B2 (en) 2015-01-22 2020-02-04 Alibaba Group Holding Limited Methods, apparatus, and systems for resource access permission management
US11763020B2 (en) * 2017-01-10 2023-09-19 Snowflake Inc. Data sharing using alias objects
US20220222365A1 (en) * 2017-01-10 2022-07-14 Snowflake Inc. Data sharing using alias objects
US10540255B2 (en) * 2017-10-31 2020-01-21 Oracle International Corporation Staged refinement for static analysis
US10992680B2 (en) * 2018-06-29 2021-04-27 Sap Se Authorization client management in a distributed computing environment
US20200007550A1 (en) * 2018-06-29 2020-01-02 Sap Se Authorization client management in a distributed computing environment
CN109697036A (en) * 2018-12-29 2019-04-30 北京金山安全软件有限公司 Information processing method and device
WO2022066414A1 (en) * 2020-09-23 2022-03-31 Amazon Technologies, Inc. Compositional reasoning techniques for role reachability analyses in identity systems
US11394661B2 (en) 2020-09-23 2022-07-19 Amazon Technologies, Inc. Compositional reasoning techniques for role reachability analyses in identity systems

Also Published As

Publication number Publication date
US20130333025A1 (en) 2013-12-12
US7933925B2 (en) 2011-04-26
US9785799B2 (en) 2017-10-10
US20080306958A1 (en) 2008-12-11
US8543607B2 (en) 2013-09-24
US20130067592A1 (en) 2013-03-14

Similar Documents

Publication Publication Date Title
US9785799B2 (en) System and method for role based analysis and access control
US9420006B2 (en) Method and system for managing security policies
US7237236B2 (en) Method and apparatus for automatically determining optimum placement of privileged code locations in existing code
US8006233B2 (en) System and method for the automatic verification of privilege-asserting and subject-executed code
US8099711B2 (en) System and method for multi-level security filtering of model representations
US8332939B2 (en) System and method for the automatic identification of subject-executed code and subject-granted access rights
Pretschner et al. Representation-independent data usage control
Pavlich-Mariscal et al. A framework of composable access control features: Preserving separation of access control concerns from models to code
US8190673B2 (en) Enforcement of object permissions in enterprise resource planning software
Buyens et al. Least privilege analysis in software architectures
Sterbenz An evaluation of the java security model
Abdellatif E2SM: a security tool for adaptive cloud‐based service‐oriented applications
Sreedhar Data-centric security: role analysis and role typestates
Mehak et al. EACF: extensible access control framework for cloud environments
Poxon Static analysis of software components for information flow security
Vanciu Static extraction of dataflow communication for security
Caron et al. Secured systems in Clouds with Model-Driven Orchestration
Fong et al. Isolating untrusted software extensions by custom scoping rules
Joseph et al. Oracle Cloud Infrastructure-A Guide to Building Cloud Native Applications
Walter Context-based Access Control and Attack Modelling and Analysis
Priyalakshmi et al. Heuristic Approach to Sustainable Agile Development with Secure Indicators
Machado Assurance and Compliance of Security Policies in Cloud-Native Environments
van DELFT et al. Programming in Paragon.
Kim et al. Pattern-based transformation rules for developing interaction models of access control systems
Fenkam et al. DPS: An architectural style for development of secure software

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SREEDHAR, VUGRANAM CHAKRAVARTHY;REEL/FRAME:017834/0072

Effective date: 20060526

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Expired due to failure to pay maintenance fee

Effective date: 20150426