WO2000060454A2 - Apparatus, methods and computer program product for secure distributed data processing - Google Patents

Apparatus, methods and computer program product for secure distributed data processing Download PDF

Info

Publication number
WO2000060454A2
WO2000060454A2 PCT/US2000/008280 US0008280W WO0060454A2 WO 2000060454 A2 WO2000060454 A2 WO 2000060454A2 US 0008280 W US0008280 W US 0008280W WO 0060454 A2 WO0060454 A2 WO 0060454A2
Authority
WO
WIPO (PCT)
Prior art keywords
security
service
user
computer
identification
Prior art date
Application number
PCT/US2000/008280
Other languages
French (fr)
Other versions
WO2000060454A3 (en
WO2000060454A8 (en
WO2000060454A9 (en
Inventor
Vincent A. George
Timothy A. Lowery
Original Assignee
Powerware Corporation
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 Powerware Corporation filed Critical Powerware Corporation
Priority to AU40405/00A priority Critical patent/AU4040500A/en
Publication of WO2000060454A2 publication Critical patent/WO2000060454A2/en
Publication of WO2000060454A3 publication Critical patent/WO2000060454A3/en
Publication of WO2000060454A8 publication Critical patent/WO2000060454A8/en
Publication of WO2000060454A9 publication Critical patent/WO2000060454A9/en

Links

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/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates

Definitions

  • the present invention relates to distributed data processing apparatus, systems and computer products therefor, and more particularly, to apparatus, methods and computer program products for secure distributed data processing.
  • a typical distributed computing environment 100 includes a plurality of computers 110 or computer-controlled devices 120, a respective one of which executes a respective control program 130 designed according to a procedural programming paradigm, e.g., a sequential series of steps performed by the computer 110 or device 120.
  • the programs 130 typically interact with one another over communications links forming a network 150, typically using specialized communications interfaces.
  • the computer programs forming the nodes of the distributed computing system are fixed, predefined entities written in platform-specific languages. Communications between the programs typically is confined to limited, predefined modes using communications interfaces incorporated into the control programs. For example, a computer program running at one node of such a system typically might only supply a predefined parameter to a memory location at another node or an interrupt used in the sequential processing of another program at another node.
  • the receiving program typically includes a corresponding data retrieval or interrupt service routine hard-coded into the application program. Modifying the parameters or other information passed between computing nodes typically is a cumbersome task, involving the rewriting and recompiling of the source code for each program. Accordingly, in such environments, modification and expansion of capabilities typically is a slow and expensive process.
  • the object paradigm has become the dominant paradigm for software standardization. According to the object-oriented computing paradigm, applications are organized as collections of interacting objects. Each object typically is an encapsulated, self-contained code entity that provides one or more services upon a request received from a client, such as another object, via an "interface.” An object typically is an instance of a "class,” an object template that defines the data and methods of objects. The internal operations and data of the object are typically inaccessible to the requesting client apart from the "public methods", exposed via an interface, which are defined for the object. Consequently, the internal data and operations of an object can be modified without affecting other objects.
  • Objects typically exhibit the characteristic of "inheritance,” meaning that a new object class can be created as “extensions" of an old object class, inheriting the methods and data of the old object to which new methods and data can be added.
  • the result is a powerful, modular structure that allows for rational segmentation of application tasks and reuse of existing code.
  • CORBA Common Object Request Broker Architecture
  • OMG Object Management Group
  • ORBs Object Request Brokers
  • a first ORB at the first computer translates the object call into an appropriate data stream, which is communicated between the first and second computers.
  • a second ORB at the second computer translates the received data stream into an equivalent object call suitable for the second object.
  • the ORBs typically are pieces of software developed to create a standardized object call mechanism on a specific platform.
  • CORBA CORBA Specifications for CORBA are provided by OMG at http://www.omg.com. Similar remote object functionality is provided in other distributed component architectures, such as the Distributed Component Object Model (DCOM) described in the white paper entitled “DCOM Architecture ,” published by Microsoft Corporation (1998), and available at http://www.microsoft.com, and the JAN A® Remote Method Invocation (RMI) system, an extension of the JAVA® language produced by Sun Microsystems, Inc., and described in the "The Java TutoriaV maintained by Sun Microsystems at http://java.sun.com.
  • DCOM Distributed Component Object Model
  • RMI Remote Method Invocation
  • the distributed-object architectures described above incorporate security features designed to reduce the likelihood of malicious or unauthorized access to distributed objects.
  • the JAVA® security model in version 1.0 of the Java Development Kit (JDK) operates according to a "sandbox" metaphor in which applets, i.e., bytecode operative to run on a JAVA® Virtual Machine (JVM), downloaded from an "untrusted" remote source are given access to a limited resources at the physical machine on which the JVM is running.
  • Compilers and a bytecode verifier ensure that only legitimate JAVA® bytecode is executed at runtime, while a SecurityManager object class restricts access of untrusted code to certain "dangerous" operations by brokering requests to invoke these operations.
  • JDK JDK Versions 1.1 and 1.2 of the JDK have expanded the sandbox metaphor to include additional concepts. These and other features of JAVA® are described in "Java Security,” available at http://java.sun.com/products/jdk/L2/docs/ guide/security/index.html. Similar techniques are described in the aforementioned DCOM Architecture white paper and in the "CORBA Security Service Specification," version 1.5, published by OMG (December 15, 1998).
  • the aforementioned distributed object architectures typically provide a security framework upon which application developers can build more detailed security implementations suited to the particular security needs of the application, as application security needs can vary widely. For example, only minimal security protections may be needed for non-critical applications, while nearly impenetrable barriers may be needed for application dealing with sensitive information such as personal or financial records. Some applications may need varying levels of security information for different aspects of the application.
  • a computer network management application may include a variety of hardware and software monitoring and control functions that have varying security needs.
  • a typical computer network comprises a variety of different hardware components, such as servers, workstations, mass storage units, hubs, routers and other communications devices, as well as uninterruptible power supplies (UPSs) and other power control elements that provide active and/or standby power to these devices.
  • the network will also typically include a variety of software elements, such as server programs accessible from client workstations and applications programs such as word processors or spreadsheets that are resident on individual workstations.
  • a network manager typically needs the ability to monitor pieces of equipment for signs of failure or degraded operation.
  • the network manager typically also needs the ability to shut down or reconfigure components to compensate for failures or degraded operations, as well as the ability to control software applications that may need to be shut down or otherwise controlled to maintain data integrity. Beyond this, it may be desirable for a network manager to be able to invoke operations that, for example, page or e-mail maintenance personnel in response to the occurrence of a network event.
  • this type of monitoring and control typically involves interaction with a number of distributed software objects that control the various hardware and software elements of the network, i.e., a distributed software object architecture. It usually is inadvisable to give all users (or user proxies) the power to access all objects in a network, as uncontrolled access may result in the loss of sensitive data, disruption of system operations, and other undesirable effects. However, it may also be undesirable to prevent all but a single administrator from having such power. Ideally, particular users should be given limited, user-specific rights to data and methods of particular objects, in a manner that is easily scaled and expanded. Accordingly, there is a continuing need for improved user- specific security techniques for distributed object environments.
  • UPSs uninterruptible power supplies
  • a client e.g., a process or object resident at first computer
  • the Service Access Manager object includes an embedded user-specific security identification, e.g., a Security Certificate object, which may be propagated to security-enabled Service objects that perform various operations at a computer.
  • the Service objects are instantiated by the Service Access Manager object at the behest of the client, and include the security identification embedded therein.
  • a Service object may then provide method-level, user- specific security at the computer in response to method calls from the client, using validation calls that pass the embedded security identification and a required right (or set of rights) to a Security Manager object, also resident at the computer, which compares the passed information to security information it maintains. Accordingly, method-level security identity can be implemented and propagated in a manner transparent to the client, and without requiring an inordinate amount of traffic between the client and the computer.
  • a user-specific Service Access Manager object is instantiated at a computer in response to a request for access for a user at a client, e.g., an object or other process resident at the same computer, or at a second, remote computer.
  • the Service Access Manager object includes a first security identification, e.g., a Security Certificate object, that is specific to the user.
  • a reference for the security- enabled Service Access Manager object is returned to the client.
  • a service request method call requesting a service is performed to the Service Access Manager object from the client.
  • a user-specific Service object is instantiated at the computer if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class.
  • the Service object include a second security identification specific to the user identified in the first security identification embedded therein.
  • a reference for the user-specific Service object is returned to the client, which may then perform an operation request method call to the Service object, the operation request method call requesting an operation by the Service object.
  • the operation is conditionally performed based on whether the user identified in the second security identification is authorized to invoke the operation request method.
  • a security validation method call is made to a Security Manager object from the Service Access Manager object in response to the service request method call, the security validation method call communicating the first security identification and a constructor right required to instantiate an instance of the Service object's class and requesting an indication of whether the user identified by the first security identification has the required constructor right.
  • the Security Manager object responsively determines whether the user identified by the first security identification has the required constructor right at the Security Manager object, and returns a second security identification identifying the user identified in the first security identification to the Service Access Manager object if the user identified by the first security identification has the required constructor right.
  • the Service Access Manager object instantiates a user-specific Service object including the second security identification embedded therein.
  • a second security validation method call is made to the Security Manager object from the Service object in response to the operation request method call, the security validation method call communicating the second security identification and a right required to invoke to the operation request method and requesting an indication of the whether the user identified by the second security identification has the required invocation right.
  • the Security Manager object responsively returns an indication of whether the user identified by the second security identification has the required invocation right.
  • the Service object performs the requested operation if the returned indication indicates that the user identified by the second security identification has the required invocation right.
  • At least one access control list is embedded in the Security Manager object.
  • the Security Manager object checks a user identified in a security identification and a required right against the access control list to determine whether the user identified in the first security identification has the required right, and responsively returns an indication of the result of the check.
  • the access control list may be built from security information communicated to the Security Manager object from a Service Engine object that maintains a database of security information for a security domain.
  • user-specific security identifications are propagated to service objects that provide services.
  • Service Access Manager object is instantiated at a computer in response to an access request from a client, the Service Access Manager object including a security identification.
  • the security identification is propagated in a Service object instantiated by the Service Access Manager object in response to a request for a service communicated to the Service Access Manager object by the client. Performance of a method of the Service object called from the client is conditioned upon the propagated security identification and a method invocation right requirement associated with the method of the Service object.
  • a computing system includes a computer and a user-specific Service Access Manager object resident at the computer.
  • the Service Access Manager object includes a first security identification specific to a user at a client and is operative to instantiate a Service object at the first computer responsive to a service request method call from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class.
  • the system may further comprise a user-specific Service object resident at the computer, the Service object including a second security identification specific to the user identified in the first security identification, wherein the Service object is operative to conditionally perform an operation requested in an operation request method call from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method.
  • Yet another aspect of the present invention relates to computer program products comprising a computer-readable storage medium configured to instruct a computer to perform the steps of: instantiating a user-specific Service Access Manager object including a first security identification specific to a user at the computer in response to a request for access for the user at a client; returning a reference for the Service Access Manager object to the client; instantiating a user-specific Service object including a second security identification specific to the user identified in the first security identification in response to a service request method call to the Service Access Manager object from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class; returning a reference for the user-specific Service object to the client; and conditionally performing an operation requested in an operation request method call to the Service object from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method.
  • user-specific, method-level security restrictions can be implemented using user-specific security identifications that can be propagated from one object to another.
  • a flexible security architecture can be created. Improved security in distributed object-oriented computing environments can thereby be provided.
  • Fig. 1 is a schematic diagram illustrating an exemplary distributed computation and control environment.
  • Fig. 2 is a schematic diagram illustrating an exemplary computer network in which the present invention may be implemented.
  • Fig. 3 is a schematic diagram of an object architecture to which the present invention may be applied.
  • Fig. 4 is a schematic diagram of an object architecture according to an embodiment of the present invention.
  • Fig. 5 is a flowchart illustration of exemplary operations for securely managing computer operations according to an embodiment of the present invention.
  • Figs. 6-8 are schematic diagrams illustrating exemplary object architectures according to aspects of the present invention. Detailed Description of Embodiments
  • the present invention may take the form of a computer program product including a computer-usable storage medium having computer-usable program code means embodied in the medium.
  • a computer-usable storage medium having computer-usable program code means embodied in the medium.
  • Any suitable computer readable medium may be utilized including, but not limited to, hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
  • Fig. 2 illustrates an exemplary distributed computing environment in which the present invention may be practiced, more particularly, a computer network 200 including a distributed plurality of computing nodes.
  • the illustrated network includes network segments 210, linked by networking components such as hubs 220 and routers 230.
  • the network is illustrated as including servers 240 and workstations 250, and peripheral devices such as printers 260 and mass storage devices 270.
  • Also included in the network 200 are networked support devices such as uninterruptible power supplies 280 that provide power to devices such as servers 240, workstations 250 and the like.
  • each of the components 220, 230, 240, 250, 260, 280 of the network 200 may be viewed as a "computers", i.e., a locus at which computational operations may be performed.
  • Basic operations of each of these components are well known to those skilled in the art, and need not be discussed in detail to understand the nature of the methods, apparatus and computer program products according to the present invention.
  • the network 200 is provided as an example only, and that the methods, apparatus and computer program products according to the present invention are applicable to a variety of other computing environments and network configurations, and to a variety of other types of computer devices. Fig.
  • a UPS 280 typically is a computer-controlled device.
  • the UPS may include an integral computer that interfaces with the network 200 in a manner similar to a server 240 or workstation, or may be a "dumb" device which is controlled by a computer networked to the UPS 280.
  • the control functions may include, for example, the ability to monitor the state of batteries included in the UPS 280 and of AC line power supplied to the UPS, as well as the ability to command the UPS to shut down.
  • object oriented programs are composed of various types of "objects".
  • An object typically includes two parts, a data structure, also referred to as a "frame”, and a set of operations or functions, also referred to as "methods", for accessing and manipulating the data structure.
  • Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a "class.”
  • Objects are typically instances created from a particular class, and typically do not exist until run-time. Classes, however, are typically fixed at build-time.
  • Each object inherits the data structure and methods of the particular class from which it was instantiated.
  • a hierarchical inheritance relationship exists between multiple classes. For example, one class may be considered a "parent” of another class (the "child” of the parent class). The child class is "derived" from the parent class and inherits all of the attributes and methods of the parent class.
  • An object typically includes an external interface that defines the manner in which data and methods of the object can be accessed by entities, e.g., other objects, outside the object.
  • the interface essentially renders the internal operations of the object transparent to outside entities, which allows objects to be altered without changing the object's interaction with outside entities.
  • the encapsulated nature of objects also makes them particularly suited for code reuse.
  • a first or "client” object may send request messages to a second or “server” object to invoke operations performed by the server object.
  • Such operations may include, for example, mathematical computations, behavioral modeling, initiation of operating system procedure, or the creation of other objects.
  • the typical request is often referred to as a "method call," i.e., a message invoking a defined method of the target object and, possibly, including parameters associated with the invoked method.
  • JAVA® is an object-oriented programming language developed by Sun Microsystems, Mountain View, California.
  • JAVA® is a portable and architecturally neutral language.
  • JAVA® source code is compiled into a machine-independent format that can be run on any machine with a JAVA® runtime system known as a JAVA® Virtual Machine (JVM).
  • JVM JAVA® Virtual Machine
  • a JVM is implemented in a computer using platform-specific software that runs on the computer.
  • the use of the JVM provides portability, allowing machines with diverse operating systems, including UNIX®, Windows 95®, Windows NT®, and Macintosh®, to execute the same JAVA® programs.
  • Exemplary "computers” in which the present invention may be utilized may include, for example, Sun Microsystems®, Apple®, IBM®, and IBM®-compatible personal computers, servers and workstations, as well as computer-controlled peripheral devices such as disk arrays, printers and plotters, as well as computer-controlled devices such as "intelligent appliances” developed in compliance with the JAVA® standard.
  • Exemplary operating systems within which the present invention may be utilized include, but are not limited to, UNIX®, Windows 95®, Windows 98®, and Windows NT®.
  • a conceptual representation of a distributed control application in an object-oriented environment is provided in Fig. 3.
  • a client 312 for example, an application program object on a first computer 310 (e.g., a server 240 or a workstation 250 illustrated in Fig. 2), is operatively associated with a Service object 322 resident on a second computer 320.
  • the Service object 322 is, in turn, operatively associated with a device 330, for example, an uninterruptible power supply (UPS).
  • UPS uninterruptible power supply
  • Methods of the Service object 322 may, for example, perform various monitoring and control functions specific to the device 330. The functions may be performed, for example, in response to method calls for the Service object 322 defined in the Service object's public interface. Such method calls may be invoked by the client 320, for example, using a distributed object oriented system architecture such as that provide by JAVA® RMI, CORBA, DCOM or the like.
  • Fig. 3 is only a skeletal conceptual illustration, and that the present invention encompasses a wide variety of other software object configurations.
  • the Service object 322 may comprise a plurality of cooperating software elements or objects that interact to provide the control and monitoring functions described above. These elements or objects may be resident at a single location, or may be distributed among several computing devices.
  • the security techniques described herein are also applicable to a client 312 that is resident on the same computer or other device as the Service object 322, and need not be limited to the remote client configuration illustrated in Fig. 3.
  • Figs. 4-8 provide object architecture diagrams and a flowchart illustration that illustrate exemplary object architectures and operations for securely managing computer operations in an object-oriented environment.
  • the architectures and operations illustrated in Figs. 4-8 are implemented in the Talon distributed object system developed by Powerware Corporation (formerly Exide Electronics, Inc.), the assignee of the present invention.
  • Talon is a JAVA® -based software system and architecture operative to implement monitoring and control functions for network elements such as uninterruptible power supplies.
  • Talon makes use of the distributed-object JAVA® RMI system that is provided by Sun Microsystems as an extension to the basic JAVA® language, as described in the aforementioned "The Java tutorial. " Talon may be used to implement a variety of monitoring and control functions, such as monitoring of software processes that may be power-dependent, generation of alarms, printouts, wireless paging and the like, as well as simulation of "what if scenarios and other functions related to strategic network power management. It will be understood that although the following description is oriented to strategic network power management, systems, methods and computer program products according to the present invention are applicable to a variety of other network applications.
  • each block of Figs. 4-8, and combinations of blocks in these illustrations can be implemented by computer program instructions.
  • These computer program instructions may be provided to a processor or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the processor or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks.
  • These computer program instructions may also be stored in a computer-readable memory that can direct a processor or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the functions specified in the block or blocks.
  • the computer program instructions may also be executed by a processor or other programmable data processing apparatus to cause a series of operational steps to be performed by the processor or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks. Accordingly, blocks of Figs. 4-8 support apparatus for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions.
  • Fig. 4 illustrates an exemplary object architecture 400 according to the present invention, including a Service User Validation object 324.
  • the Service User Validation object 324 is operatively associated with a Security Manager object 328 that maintains one or more Access Control Lists (ACLs) 401 that cross-reference a user with operational rights granted to the user by a system administrator or similar function.
  • ACLs Access Control Lists
  • the Security Manager object maintains a list of users, each having a set of ACLs associated therewith that determine the user's operational rights. Creation of the Service User Validation object 324 and the Security Manager object 328 are described in greater detail below with reference to Fig. 6. For purposes of the following discussion of Figs. 4 and 5, the Service User Validation object 324 and the Security Manager Object 328 will be described in relation to their respective roles in propagating security rights according to embodiments of the present invention.
  • the Service User Validation object 324 Prior to initiating access to a service provided at a computer, a client 312, which may comprise an object resident on another computer apart from a computer at which the Service User Validation object 324 and the Security Manager object 328 are resident, gains reference to the Service User Validation object 324.
  • the Service User Validation object 324 comprises a "Talon Service" object for which a reference is provided via a JAVA® RMI registry.
  • the registry provides a public index with which objects are "registered," i.e., a database from which an object or other process may obtain a reference to another object in a distributed object system.
  • JAVA® RMI registry operations are known to those skilled in the art, and a description thereof may be found in the aforementioned "The Java tutorial.”
  • Access to a specific service provided on a computer is initiated by requesting access for a user at the client (Block 505), where the "user” may comprise, for example, a human user physically interacting with a user interface provided by the client, or a user proxy such as an application program that possesses user security credentials.
  • this request is specifically embodied in a getServiceAccessManager (username, password) method call that passes username and password information from the • client 312 to the Service User Validation Object 324.
  • the Service User Validation object 324 instantiates a user-specific security-enabled Service Access Manager object 326 that includes a user-specific security identification, e.g., a user-specific Security Certificate object 411, embedded therein (Block 510), and returns a reference 313 to the Service Access Manager object 326 to the client 312 (Block 515). More specifically, in response to the request for access, the Service User Validation
  • Object 324 performs a user validation method call that communicates a user identification and password (or similar user-specific security information) to the Security Manager object 328.
  • the Security Manager object 328 checks the identified user and password against a list of authorized users. If the communicated username and password combination is invalid, the Security Manager object 328 returns a security exception that prevents further access.
  • the Security Manager object 328 returns a user-specific security identification to the Service User Validation object 324.
  • this validation method call is achieved via a newTalonSecurityCertificate (username, password) call returns a Security Certificate object 411 that identifies the user in a context maintained by the Security Manager object 328.
  • the returned Security Certificate object 411 is embedded into a Service Access Manager object 326 instantiated by the Service User Validation object.
  • a reference 313 to the Service Access Manager object 326 is then returned to the client 312 (Block 515).
  • the client 312 can then use the reference 313 to gain access to specific operations, by using the security-enabled Service Access Manager object 326 to instantiate a user-specific Service object 322, e.g., an object that performs specific monitoring or control operations relating to a hardware or software element in a computer network.
  • the client 312 performs a service request method call to the Service Access Manager object 326 using the reference 313 (Block 520). For example, in the Talon system, this involves invocation of a getService (service) method call from the client 312, wherein the getService method call passes a parameter identifying a service to which the client 312 desires to gain access.
  • the Service Access Manager object 326 instantiates a user-specific security-enabled Service object 322 that performs operations of the requested service, based on whether the user identified by the Security Certificate object 411 embedded in the Service Access Manager Object 326 has a valid constructor right to instantiate such an object (Block 525).
  • a reference 314 to the newly-instantiated Service object 322 is then returned to the client 312 (Block 530).
  • the Service Access Manager object 326 performs a security validation method call to the Security Manager object 328, wherein the security validation method call identifies a user identified by the security identification embedded in the Service Access Manager object 326 and a constructor right required to instantiate objects of the Service object's 322 class.
  • this validation comprises invocation of a validateSecurityAccess (security certificate, constructor right) method call that communicates the Security Certificate object 411 embedded in the Service Access Manager object 326, along with one or more required constructor rights associated with the requested service.
  • the user identified by the Security Certificate object 411 and the constructor right(s) are checked against the one or more Access Control Lists (ACLs) 401 maintained by the Security Manager object 328.
  • ACLs Access Control Lists
  • an ACL contains security attributes used to perform security validation.
  • Multiple ACLs may be maintained by the Security Manager object 328, including a user ACL and ACLs for each security entity in the security model, e.g., for each method call for which security is desired.
  • the Security Manager object 328 returns a new Security Certificate object 411 associated with the user identified by the Security Certificate object 411 originally passed to the Security Manager object 328.
  • the returned Security Certificate object 411 is embedded in a new, user-specific Service object 322 instantiated by the Service Access Manager object 326.
  • the client may then perform an operation method call to the Service object 322 using the returned Service object reference 314 (Block 535).
  • the Service object 322 may perform the requested operation conditioned upon whether the user identified by the security identification 412 embedded therein is authorized to invoke the requested operation method (Block 540).
  • the Service object 322 may make a method call to the Security Manager Object 328 that identifies the user identified by the Security Certificate object 411 and a method invocation right required to perform the particular method. In the aforementioned Talon system, this is achieved with a validateSecurityAccess(certificate, service method right) call to the Security Manager object 328.
  • the Security Manager 328 checks the user identified by the Security Certificate object 411 and the required method invocation right against its ACL 401, and returns an indication of whether the user has the required right. Assuming the Security Manager object 328 returns a positive indication, the Service object 322 then performs the requested operation.
  • Fig. 6 illustrates exemplary operations 600 for using a security-enabled Service object
  • Fig. 6 illustrates a client 312 resident at a first computer 310.
  • the client possesses a reference 314 to a user-specific security-enabled MyUPS object 322 that includes a user-specific Security Certificate object 411.
  • the client performs a ShutdownUPS("now") method call to the MyUPS object 322 using the reference 314, wherein the call communicates a parameter "now" that indicates that the client 312 desires to command a UPS 330 to shut down immediately.
  • the MyUPS object 322 performs a validateSecurityAccess(certificate, "shutdown") call to the Security Manager object 328.
  • the validateSecurityAccess (certificate, "shutdown") passes two parameters, the Security Certificate object 411 and a "shutdown" right required to perform the called method.
  • the Security Manager object 328 checks these parameters against the ACL 401, e.g., against the set of ACLs associated with the identified user, returning an indication of whether the user associated with the Security Certificate object 411 has the required "shutdown" right.
  • the MyUPS object 322 performs the requested method, causmg a series of operational steps to be performed in a JVM 321 and the second computer 320 needed to command the UPS 330 to shut down.
  • control of the UPS 330 from the computer 320 may involve execution of software drivers (not shown) resident on the computer 320 that provide an interface to the UPS 330.
  • specific commands and/or command formats sent to the UPS 330 are generally specific to the UPS 330, e.g., are dependent on the make and manufacturer of the UPS 330. Details of such elements, commands and command formats are known to those skilled in the art and are not discussed in detail herein.
  • Fig. 6 illustrates ways in which a service object, such as the MyUPS object 322, may implement user-specific, method-level security, i.e., by performing a validation method call to the Security Manager object 328. It will be understood, however, that a service object is not required to make a security validation call for every method request it receives from a client. Rather, the systems, methods and computer program products of the present invention provide a flexible framework for selectively providing user-specific, method-level security.
  • the exact manner in which security is provided to a service object such as the MyUPS object of Fig. 6 can be determined, for example, by the manner in which the service object is constituted, e.g., by the specific methods included in the service objects class, either directly or by inheritance from other object classes.
  • FIG. 7 illustrates exemplary operations 700 according to another aspect of the present invention, showing how the distributed security described above may be expanded across multiple platforms in a network.
  • a client 312 resident at a first computer 310 possesses a reference 314a to a user-specific security-enabled MyUPS object 322a on a second computer 320a.
  • the MyUPS object 322a includes a user-specific Security Certificate object 411, instantiated by a Security Access Manager object 326a.
  • the client performs a MonitorUPS("battery”) method call to the MyUPS object 322a using the reference 314a, wherein the call communicates a parameter "battery" that indicates that the client 312 desires to monitor the state of a battery at a UPS 330a.
  • the MyUPS object 322a performs a validateSecurityAccess(certificate, "monitor") call to the Security Manager object 328a.
  • the validateSecurityAccess(certificate, "monitor”) passes two parameters, the Security Certificate object 411 and a "monitor" right required to perform the called method.
  • a Security Manager object 328a checks these parameters against its ACL 401a, returning an indication of whether the user associated with the Security Certificate object 411 has the required "monitor" right.
  • the MyUPS object 322a performs the requested method, causing a series of operational steps in a JVM 321a and the second computer 320a needed to return the status information from the UPS 330a to the client 312.
  • the client 312 may use the status information so obtained to invoke operations at a third computer 320b.
  • the client 312 also possesses a reference 314b to a user-specific security-enabled MyPage object 322b on the third computer 320a.
  • the MyPage object 322b includes a user-specific Security Certificate object 411, instantiated by a Security Access Manager object 326b.
  • the client 312 performs a Page("maintenance ", "message ") method call to the MyPage object 322b using the reference 314b, wherein the call communicates a parameter "maintenance” that indicates that the client 312 desires to send a "message” to maintenance personnel regarding the status of the battery at the UPS 330a.
  • the MyPage object 322b performs a validateSecurityAccess(certificate, "page”) call to the Security Manager object 328b.
  • the validateSecurityAccess(certificate, "page”) call passes two parameters, the Security Certificate object 411 and a "page” right required to perform the called method.
  • a Security Manager object 328b checks these parameters against its ACL 401b, returning an indication of whether the user associated with the Security Certificate object 411 has the required "page" right. If the Security Manager object 328b returns a positive indication, the MyPage object 322b performs the requested method, causing a series of operational steps in a JVM 321b and the third computer 320b needed to effect transmission of the page message from a modem 330b connected to the third computer 320b. It will be appreciated that the embodiments illustrated in Figs. 6 and 7 are illustrative, and that the present invention is not limited to the architectures and operations shown. For example, much more elaborate object relationships may be used with the present invention.
  • control of the UPS 330a and the modem 330b of Fig. 7 may involve the interaction of a variety of different service objects on a variety of object hierarchy levels.
  • Security identifications e.g., Security Certificate objects
  • Security identifications may be propagated to these objects in many ways.
  • Security identifications may be propagated directly from a Service Access Manager object as shown, or may be propagated from a parent service object class to subclasses of the parent service object class.
  • FIG. 8 illustrates exemplary distribution and maintenance of security information in a distributed object environment according to another aspect of the present invention.
  • a security domain 800 is defined, including a plurality of Service Engine objects 830a, 830b resident on respective computers 810a, 810b, executing on respective JVMs 811a, 811b.
  • the engine objects 830a, 830b reside at the heads of object hierarchies including Service User Validation objects 324a, 324b and Security Manager Objects 326a, 326b, including respective access control lists 410a, 401b.
  • security-enabled Service Access Manager objects 326a, 326b and security enabled Service Objects 332a, 332b which may be assigned to a plurality of different users recognized in the domain 800.
  • One of the Service Engine objects 830a serves as "domain controller," i.e., an object responsible for maintaining and distributing security information from a security database 840 that includes access information for users recognized in the domain 800.
  • the domain controller Service Engine object 830a ensures, for example, that appropriate security information is replicated in an ACL 401b used by the Security Manager object 830b on the second computer 810b. Typically, this may occur when the second Service Engine 830b is instantiated, and intermittently during the lifetimes of the Service Engine objects 830a, 830b, for example, when user security privileges are added or removed by a system administrator invoking methods of the domain controller Service Engine 830a.

Abstract

A user-specific Service Access Manager object is instantiated at a computer in response to a request for access for a user at a client, e.g., an object or other process resident at a second computer. The Service Access Manager object includes a first security identification, e.g., a Security Certificate object, which is specific to the user. A reference for the Service Access Manager object is returned to the client. A service request method call requesting a service is performed to the Service Access Manager object from the client. A user-specific Service object is instantiated at the computer if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class, the Service object including a second security identification specific to the user identified in the first security identification. A reference for the user-specific Service object is returned to the client, which may then perform an operation request method call to the Service object, the operation request method call requesting an operation by the Service object. The operation is conditionally performed based on whether the user identified in the second security identification is authorized to invoke the operation request method. Responses to the service request and operation request methods calls preferably are conditioned upon validation calls to a Security Manager object that checks a security identification and a required method invocation right against an access control list. Related systems and computer program products are discussed.

Description

APPARATUS, METHODS AND COMPUTER PROGRAM PRODUCTS
FOR SECURE DISTRIBUTED DATA PROCESSING USING USER-SPECIFIC
SERVICE ACCESS MANAGERS AND PROPAGATED SECURITY
IDENTIFICATIONS
Cross-Reference to Related Application
This application is related to Application Serial No. 09/285,394 (Attorney Docket No. 9060-169) filed concurrently herewith, entitled Systems, Methods and Computer Program Products for Event and Action Management in a Distributed Computing Environment, to Curtin, Jr. et al, assigned to the assignee of the present application, the disclosure of which is hereby incorporated herein by reference.
Field of the Invention The present invention relates to distributed data processing apparatus, systems and computer products therefor, and more particularly, to apparatus, methods and computer program products for secure distributed data processing.
Background of the Invention Distributed computation and control are widely used in information processing systems and in such applications as power distribution, industrial control and telephone network control. As illustrated in Fig. 1, a typical distributed computing environment 100 includes a plurality of computers 110 or computer-controlled devices 120, a respective one of which executes a respective control program 130 designed according to a procedural programming paradigm, e.g., a sequential series of steps performed by the computer 110 or device 120. The programs 130 typically interact with one another over communications links forming a network 150, typically using specialized communications interfaces.
One of the disadvantages of traditional distributed computing systems is their relative inflexibility. Typically, the computer programs forming the nodes of the distributed computing system are fixed, predefined entities written in platform-specific languages. Communications between the programs typically is confined to limited, predefined modes using communications interfaces incorporated into the control programs. For example, a computer program running at one node of such a system typically might only supply a predefined parameter to a memory location at another node or an interrupt used in the sequential processing of another program at another node. The receiving program typically includes a corresponding data retrieval or interrupt service routine hard-coded into the application program. Modifying the parameters or other information passed between computing nodes typically is a cumbersome task, involving the rewriting and recompiling of the source code for each program. Accordingly, in such environments, modification and expansion of capabilities typically is a slow and expensive process.
The increasing capability and decreasing cost of computing hardware has generally led to an increase in the demands on and complexity of software. The size and scope of software applications have generally increased and, consequently, increased interoperability is generally desirable, as interoperability can facilitate collaborative development of software applications. Typically, this means the development of standardized software elements that can ease the work involved in building and modifying applications. Standardization can also enable programmers to reuse existing code in new applications, reducing time to market.
The object paradigm has become the dominant paradigm for software standardization. According to the object-oriented computing paradigm, applications are organized as collections of interacting objects. Each object typically is an encapsulated, self-contained code entity that provides one or more services upon a request received from a client, such as another object, via an "interface." An object typically is an instance of a "class," an object template that defines the data and methods of objects. The internal operations and data of the object are typically inaccessible to the requesting client apart from the "public methods", exposed via an interface, which are defined for the object. Consequently, the internal data and operations of an object can be modified without affecting other objects. Objects typically exhibit the characteristic of "inheritance," meaning that a new object class can be created as "extensions" of an old object class, inheriting the methods and data of the old object to which new methods and data can be added. The result is a powerful, modular structure that allows for rational segmentation of application tasks and reuse of existing code.
Early object-oriented programming environments were typically limited to operation within a single machine, i.e., the data and methods of objects instantiated within a program space created at the machine could be accessed by other objects instantiated on the same machine, but typically could not be accessed from outside of the machine. As such, the power of object-oriented programming tended to be limited in distributed applications spread across multiple computers or other computing devices, as communications between objects in different program spaces generally could not utilize standard object communication techniques. However, modern systems have extended the object paradigm beyond the individual computer. Distributed object computing architectures have been developed that enable objects resident on one computer of a network to access the data and methods of objects resident on other computers of the network as if they were local objects, in some cases, even if the objects on the different computers were written in different programming languages. For example, the Common Object Request Broker Architecture (CORBA) standard, a software standard maintained by the Object Management Group (OMG), defines specialized interfaces or "Object Request Brokers" (ORBs) that provide translation of an object call made by a first object at a first computer to a second object at a second computer such that, from the standpoint of the objects, the call appears as a normal "local" object call. A first ORB at the first computer translates the object call into an appropriate data stream, which is communicated between the first and second computers. A second ORB at the second computer translates the received data stream into an equivalent object call suitable for the second object. The ORBs typically are pieces of software developed to create a standardized object call mechanism on a specific platform. Specifications for CORBA are provided by OMG at http://www.omg.com. Similar remote object functionality is provided in other distributed component architectures, such as the Distributed Component Object Model (DCOM) described in the white paper entitled "DCOM Architecture ," published by Microsoft Corporation (1998), and available at http://www.microsoft.com, and the JAN A® Remote Method Invocation (RMI) system, an extension of the JAVA® language produced by Sun Microsystems, Inc., and described in the "The Java TutoriaV maintained by Sun Microsystems at http://java.sun.com.
As the object-oriented paradigm has expanded across networks, however, security has become a paramount concern. Applications that comprise objects distributed among several computers can be very vulnerable to security breaches. Malicious code, such as computer viruses, can gain access to object methods and data and wreak havoc with applications. Unauthorized users can gain access to sensitive data or can invoke unauthorized operation of software or hardware that is controlled by software objects.
The distributed-object architectures described above incorporate security features designed to reduce the likelihood of malicious or unauthorized access to distributed objects. For example, the JAVA® security model in version 1.0 of the Java Development Kit (JDK), developed by Sun Microsystems, operates according to a "sandbox" metaphor in which applets, i.e., bytecode operative to run on a JAVA® Virtual Machine (JVM), downloaded from an "untrusted" remote source are given access to a limited resources at the physical machine on which the JVM is running. Compilers and a bytecode verifier ensure that only legitimate JAVA® bytecode is executed at runtime, while a SecurityManager object class restricts access of untrusted code to certain "dangerous" operations by brokering requests to invoke these operations. Versions 1.1 and 1.2 of the JDK have expanded the sandbox metaphor to include additional concepts. These and other features of JAVA® are described in "Java Security," available at http://java.sun.com/products/jdk/L2/docs/ guide/security/index.html. Similar techniques are described in the aforementioned DCOM Architecture white paper and in the "CORBA Security Service Specification," version 1.5, published by OMG (December 15, 1998). The aforementioned distributed object architectures typically provide a security framework upon which application developers can build more detailed security implementations suited to the particular security needs of the application, as application security needs can vary widely. For example, only minimal security protections may be needed for non-critical applications, while nearly impenetrable barriers may be needed for application dealing with sensitive information such as personal or financial records. Some applications may need varying levels of security information for different aspects of the application.
For example, a computer network management application may include a variety of hardware and software monitoring and control functions that have varying security needs. A typical computer network comprises a variety of different hardware components, such as servers, workstations, mass storage units, hubs, routers and other communications devices, as well as uninterruptible power supplies (UPSs) and other power control elements that provide active and/or standby power to these devices. In addition to these hardware elements, the network will also typically include a variety of software elements, such as server programs accessible from client workstations and applications programs such as word processors or spreadsheets that are resident on individual workstations.
Comprehensive monitoring and control of these hardware and software elements typically requires the ability to monitor the status of individual components, as well as the ability to control individual elements. For example, a network manager (either human or automatic) typically needs the ability to monitor pieces of equipment for signs of failure or degraded operation. In addition, the network manager typically also needs the ability to shut down or reconfigure components to compensate for failures or degraded operations, as well as the ability to control software applications that may need to be shut down or otherwise controlled to maintain data integrity. Beyond this, it may be desirable for a network manager to be able to invoke operations that, for example, page or e-mail maintenance personnel in response to the occurrence of a network event.
In a modern computer network, this type of monitoring and control typically involves interaction with a number of distributed software objects that control the various hardware and software elements of the network, i.e., a distributed software object architecture. It usually is inadvisable to give all users (or user proxies) the power to access all objects in a network, as uncontrolled access may result in the loss of sensitive data, disruption of system operations, and other undesirable effects. However, it may also be undesirable to prevent all but a single administrator from having such power. Ideally, particular users should be given limited, user-specific rights to data and methods of particular objects, in a manner that is easily scaled and expanded. Accordingly, there is a continuing need for improved user- specific security techniques for distributed object environments.
Summary of the Invention In light of the foregoing, it is an object of the present invention to provide systems, methods and computer program products for securely managing a distributed object environment.
It is another object of the present invention to provide systems, methods and computer program products for secure monitoring and control of network elements such as uninterruptible power supplies (UPSs).
These and other objects, features and advantages are provided according to the present invention by systems, methods and computer program products in which a client, e.g., a process or object resident at first computer, is provided with a reference to a security- enabled Service Access Manager object. The Service Access Manager object includes an embedded user-specific security identification, e.g., a Security Certificate object, which may be propagated to security-enabled Service objects that perform various operations at a computer. The Service objects are instantiated by the Service Access Manager object at the behest of the client, and include the security identification embedded therein. Using the embedded security identification, a Service object may then provide method-level, user- specific security at the computer in response to method calls from the client, using validation calls that pass the embedded security identification and a required right (or set of rights) to a Security Manager object, also resident at the computer, which compares the passed information to security information it maintains. Accordingly, method-level security identity can be implemented and propagated in a manner transparent to the client, and without requiring an inordinate amount of traffic between the client and the computer.
In particular, according to an aspect of the present invention, a user-specific Service Access Manager object is instantiated at a computer in response to a request for access for a user at a client, e.g., an object or other process resident at the same computer, or at a second, remote computer. The Service Access Manager object includes a first security identification, e.g., a Security Certificate object, that is specific to the user. A reference for the security- enabled Service Access Manager object is returned to the client. A service request method call requesting a service is performed to the Service Access Manager object from the client. A user-specific Service object is instantiated at the computer if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class. The Service object include a second security identification specific to the user identified in the first security identification embedded therein. A reference for the user-specific Service object is returned to the client, which may then perform an operation request method call to the Service object, the operation request method call requesting an operation by the Service object. The operation is conditionally performed based on whether the user identified in the second security identification is authorized to invoke the operation request method.
According to another aspect of the present invention, a security validation method call is made to a Security Manager object from the Service Access Manager object in response to the service request method call, the security validation method call communicating the first security identification and a constructor right required to instantiate an instance of the Service object's class and requesting an indication of whether the user identified by the first security identification has the required constructor right. The Security Manager object responsively determines whether the user identified by the first security identification has the required constructor right at the Security Manager object, and returns a second security identification identifying the user identified in the first security identification to the Service Access Manager object if the user identified by the first security identification has the required constructor right. In response, the Service Access Manager object instantiates a user-specific Service object including the second security identification embedded therein. According to another aspect of the present invention, a second security validation method call is made to the Security Manager object from the Service object in response to the operation request method call, the security validation method call communicating the second security identification and a right required to invoke to the operation request method and requesting an indication of the whether the user identified by the second security identification has the required invocation right. The Security Manager object responsively returns an indication of whether the user identified by the second security identification has the required invocation right. In response, the Service object performs the requested operation if the returned indication indicates that the user identified by the second security identification has the required invocation right.
According to yet another aspect of the present invention, at least one access control list is embedded in the Security Manager object. In response to a security validation method call, the Security Manager object checks a user identified in a security identification and a required right against the access control list to determine whether the user identified in the first security identification has the required right, and responsively returns an indication of the result of the check. The access control list may be built from security information communicated to the Security Manager object from a Service Engine object that maintains a database of security information for a security domain.
According to another aspect of the present invention, user-specific security identifications are propagated to service objects that provide services. A user-specific
Service Access Manager object is instantiated at a computer in response to an access request from a client, the Service Access Manager object including a security identification. The security identification is propagated in a Service object instantiated by the Service Access Manager object in response to a request for a service communicated to the Service Access Manager object by the client. Performance of a method of the Service object called from the client is conditioned upon the propagated security identification and a method invocation right requirement associated with the method of the Service object.
A computing system, according to an embodiment of the present invention, includes a computer and a user-specific Service Access Manager object resident at the computer. The Service Access Manager object includes a first security identification specific to a user at a client and is operative to instantiate a Service object at the first computer responsive to a service request method call from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class. The system may further comprise a user-specific Service object resident at the computer, the Service object including a second security identification specific to the user identified in the first security identification, wherein the Service object is operative to conditionally perform an operation requested in an operation request method call from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method. Yet another aspect of the present invention relates to computer program products comprising a computer-readable storage medium configured to instruct a computer to perform the steps of: instantiating a user-specific Service Access Manager object including a first security identification specific to a user at the computer in response to a request for access for the user at a client; returning a reference for the Service Access Manager object to the client; instantiating a user-specific Service object including a second security identification specific to the user identified in the first security identification in response to a service request method call to the Service Access Manager object from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class; returning a reference for the user-specific Service object to the client; and conditionally performing an operation requested in an operation request method call to the Service object from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method.
According to the present invention, user-specific, method-level security restrictions can be implemented using user-specific security identifications that can be propagated from one object to another. In this manner, a flexible security architecture can be created. Improved security in distributed object-oriented computing environments can thereby be provided.
Brief Description of the Drawings
Fig. 1 is a schematic diagram illustrating an exemplary distributed computation and control environment.
Fig. 2 is a schematic diagram illustrating an exemplary computer network in which the present invention may be implemented. Fig. 3 is a schematic diagram of an object architecture to which the present invention may be applied.
Fig. 4 is a schematic diagram of an object architecture according to an embodiment of the present invention.
Fig. 5 is a flowchart illustration of exemplary operations for securely managing computer operations according to an embodiment of the present invention.
Figs. 6-8 are schematic diagrams illustrating exemplary object architectures according to aspects of the present invention. Detailed Description of Embodiments
The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. As will be appreciated by one of skill in the art, the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely, software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product including a computer-usable storage medium having computer-usable program code means embodied in the medium. Any suitable computer readable medium may be utilized including, but not limited to, hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
Fig. 2 illustrates an exemplary distributed computing environment in which the present invention may be practiced, more particularly, a computer network 200 including a distributed plurality of computing nodes. The illustrated network includes network segments 210, linked by networking components such as hubs 220 and routers 230. The network is illustrated as including servers 240 and workstations 250, and peripheral devices such as printers 260 and mass storage devices 270. Also included in the network 200 are networked support devices such as uninterruptible power supplies 280 that provide power to devices such as servers 240, workstations 250 and the like. Generally, each of the components 220, 230, 240, 250, 260, 280 of the network 200 may be viewed as a "computers", i.e., a locus at which computational operations may be performed. Basic operations of each of these components are well known to those skilled in the art, and need not be discussed in detail to understand the nature of the methods, apparatus and computer program products according to the present invention. It will be readily understood that the network 200 is provided as an example only, and that the methods, apparatus and computer program products according to the present invention are applicable to a variety of other computing environments and network configurations, and to a variety of other types of computer devices. Fig. 2 also illustrates an exemplary application for the apparatus, methods and computer program products according to the present invention, namely, distributed monitoring and control of processes on one node of the network 200 from another node of the network 200. For example, it may be desirable for a user to monitor status of UPSs 280 from one workstation 250 of the computer network 200. A UPS 280 typically is a computer- controlled device. For example, the UPS may include an integral computer that interfaces with the network 200 in a manner similar to a server 240 or workstation, or may be a "dumb" device which is controlled by a computer networked to the UPS 280. The control functions may include, for example, the ability to monitor the state of batteries included in the UPS 280 and of AC line power supplied to the UPS, as well as the ability to command the UPS to shut down.
Object-Oriented Computing
It will be appreciated that the distributed control applications described herein may be described in terms of object-oriented computing architectures and processes. As is well known to those having skill in the art, object oriented programs are composed of various types of "objects". An object typically includes two parts, a data structure, also referred to as a "frame", and a set of operations or functions, also referred to as "methods", for accessing and manipulating the data structure. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a "class." Objects are typically instances created from a particular class, and typically do not exist until run-time. Classes, however, are typically fixed at build-time. Each object inherits the data structure and methods of the particular class from which it was instantiated. A hierarchical inheritance relationship exists between multiple classes. For example, one class may be considered a "parent" of another class (the "child" of the parent class). The child class is "derived" from the parent class and inherits all of the attributes and methods of the parent class.
An object typically includes an external interface that defines the manner in which data and methods of the object can be accessed by entities, e.g., other objects, outside the object. The interface essentially renders the internal operations of the object transparent to outside entities, which allows objects to be altered without changing the object's interaction with outside entities. The encapsulated nature of objects also makes them particularly suited for code reuse.
In a classic object-oriented environment, a first or "client" object may send request messages to a second or "server" object to invoke operations performed by the server object. Such operations may include, for example, mathematical computations, behavioral modeling, initiation of operating system procedure, or the creation of other objects. The typical request is often referred to as a "method call," i.e., a message invoking a defined method of the target object and, possibly, including parameters associated with the invoked method. There are many different types of computer languages for creating object-oriented environments, such as JAVA®, Smalltalk or C++. JAVA® is an object-oriented programming language developed by Sun Microsystems, Mountain View, California. JAVA® is a portable and architecturally neutral language. JAVA® source code is compiled into a machine-independent format that can be run on any machine with a JAVA® runtime system known as a JAVA® Virtual Machine (JVM). A JVM is implemented in a computer using platform-specific software that runs on the computer. The use of the JVM provides portability, allowing machines with diverse operating systems, including UNIX®, Windows 95®, Windows NT®, and Macintosh®, to execute the same JAVA® programs. It will be appreciated by those skilled in the art, that computer program code for creating processes that provide functional equivalents to the object architectures described herein may also be written in conventional procedural programming languages, such as the "C" programming language, or in a functional (or fourth generation) programming language such as Lisp, SML, or Forth.
Exemplary "computers" in which the present invention may be utilized may include, for example, Sun Microsystems®, Apple®, IBM®, and IBM®-compatible personal computers, servers and workstations, as well as computer-controlled peripheral devices such as disk arrays, printers and plotters, as well as computer-controlled devices such as "intelligent appliances" developed in compliance with the JAVA® standard. However, it is to be understood that various other computing devices and processors may be utilized to carry out the present invention without being limited to those enumerated herein. Exemplary operating systems within which the present invention may be utilized include, but are not limited to, UNIX®, Windows 95®, Windows 98®, and Windows NT®.
Distributed Control in an Object-Oriented Environment A conceptual representation of a distributed control application in an object-oriented environment is provided in Fig. 3. A client 312, for example, an application program object on a first computer 310 (e.g., a server 240 or a workstation 250 illustrated in Fig. 2), is operatively associated with a Service object 322 resident on a second computer 320. The Service object 322 is, in turn, operatively associated with a device 330, for example, an uninterruptible power supply (UPS). Methods of the Service object 322 may, for example, perform various monitoring and control functions specific to the device 330. The functions may be performed, for example, in response to method calls for the Service object 322 defined in the Service object's public interface. Such method calls may be invoked by the client 320, for example, using a distributed object oriented system architecture such as that provide by JAVA® RMI, CORBA, DCOM or the like.
Those skilled in the art will appreciate that Fig. 3 is only a skeletal conceptual illustration, and that the present invention encompasses a wide variety of other software object configurations. For example, rather than a single object, the Service object 322 may comprise a plurality of cooperating software elements or objects that interact to provide the control and monitoring functions described above. These elements or objects may be resident at a single location, or may be distributed among several computing devices. In addition, the security techniques described herein are also applicable to a client 312 that is resident on the same computer or other device as the Service object 322, and need not be limited to the remote client configuration illustrated in Fig. 3.
As described above, a difficulty involved in implementing distributed object architectures is preventing malicious or other unauthorized access to objects, such as the Service object 322 of Fig. 3. With reference to Figs. 4-8, the following discussion will describe apparatus and methods for providing secure operations in such an environment. In particular, Figs. 4-8 provide object architecture diagrams and a flowchart illustration that illustrate exemplary object architectures and operations for securely managing computer operations in an object-oriented environment. The architectures and operations illustrated in Figs. 4-8 are implemented in the Talon distributed object system developed by Powerware Corporation (formerly Exide Electronics, Inc.), the assignee of the present invention. Talon is a JAVA® -based software system and architecture operative to implement monitoring and control functions for network elements such as uninterruptible power supplies. Talon makes use of the distributed-object JAVA® RMI system that is provided by Sun Microsystems as an extension to the basic JAVA® language, as described in the aforementioned "The Java Tutorial. " Talon may be used to implement a variety of monitoring and control functions, such as monitoring of software processes that may be power-dependent, generation of alarms, printouts, wireless paging and the like, as well as simulation of "what if scenarios and other functions related to strategic network power management. It will be understood that although the following description is oriented to strategic network power management, systems, methods and computer program products according to the present invention are applicable to a variety of other network applications.
It will be understood that each block of Figs. 4-8, and combinations of blocks in these illustrations, can be implemented by computer program instructions. These computer program instructions may be provided to a processor or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the processor or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a processor or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the functions specified in the block or blocks. The computer program instructions may also be executed by a processor or other programmable data processing apparatus to cause a series of operational steps to be performed by the processor or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks. Accordingly, blocks of Figs. 4-8 support apparatus for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions.
Fig. 4 illustrates an exemplary object architecture 400 according to the present invention, including a Service User Validation object 324. The Service User Validation object 324 is operatively associated with a Security Manager object 328 that maintains one or more Access Control Lists (ACLs) 401 that cross-reference a user with operational rights granted to the user by a system administrator or similar function. Preferably, the Security Manager object maintains a list of users, each having a set of ACLs associated therewith that determine the user's operational rights. Creation of the Service User Validation object 324 and the Security Manager object 328 are described in greater detail below with reference to Fig. 6. For purposes of the following discussion of Figs. 4 and 5, the Service User Validation object 324 and the Security Manager Object 328 will be described in relation to their respective roles in propagating security rights according to embodiments of the present invention.
Prior to initiating access to a service provided at a computer, a client 312, which may comprise an object resident on another computer apart from a computer at which the Service User Validation object 324 and the Security Manager object 328 are resident, gains reference to the Service User Validation object 324. For the aforementioned Talon system, the Service User Validation object 324 comprises a "Talon Service" object for which a reference is provided via a JAVA® RMI registry. In simplified terms, the registry provides a public index with which objects are "registered," i.e., a database from which an object or other process may obtain a reference to another object in a distributed object system. JAVA® RMI registry operations are known to those skilled in the art, and a description thereof may be found in the aforementioned "The Java Tutorial."
Access to a specific service provided on a computer is initiated by requesting access for a user at the client (Block 505), where the "user" may comprise, for example, a human user physically interacting with a user interface provided by the client, or a user proxy such as an application program that possesses user security credentials. In the aforementioned Talon system, this request is specifically embodied in a getServiceAccessManager (username, password) method call that passes username and password information from the client 312 to the Service User Validation Object 324. In response to the request, the Service User Validation object 324 instantiates a user-specific security-enabled Service Access Manager object 326 that includes a user-specific security identification, e.g., a user-specific Security Certificate object 411, embedded therein (Block 510), and returns a reference 313 to the Service Access Manager object 326 to the client 312 (Block 515). More specifically, in response to the request for access, the Service User Validation
Object 324 performs a user validation method call that communicates a user identification and password (or similar user-specific security information) to the Security Manager object 328. The Security Manager object 328 checks the identified user and password against a list of authorized users. If the communicated username and password combination is invalid, the Security Manager object 328 returns a security exception that prevents further access.
Assuming the username and password combination is valid, the Security Manager object 328 returns a user-specific security identification to the Service User Validation object 324. In the aforementioned Talon system, this validation method call is achieved via a newTalonSecurityCertificate (username, password) call returns a Security Certificate object 411 that identifies the user in a context maintained by the Security Manager object 328. The returned Security Certificate object 411 is embedded into a Service Access Manager object 326 instantiated by the Service User Validation object. A reference 313 to the Service Access Manager object 326 is then returned to the client 312 (Block 515). The client 312 can then use the reference 313 to gain access to specific operations, by using the security-enabled Service Access Manager object 326 to instantiate a user-specific Service object 322, e.g., an object that performs specific monitoring or control operations relating to a hardware or software element in a computer network. The client 312 performs a service request method call to the Service Access Manager object 326 using the reference 313 (Block 520). For example, in the Talon system, this involves invocation of a getService (service) method call from the client 312, wherein the getService method call passes a parameter identifying a service to which the client 312 desires to gain access. In response to the service request, the Service Access Manager object 326 instantiates a user- specific security-enabled Service object 322 that performs operations of the requested service, based on whether the user identified by the Security Certificate object 411 embedded in the Service Access Manager Object 326 has a valid constructor right to instantiate such an object (Block 525). A reference 314 to the newly-instantiated Service object 322 is then returned to the client 312 (Block 530). More specifically, in response to the service request, the Service Access Manager object 326 performs a security validation method call to the Security Manager object 328, wherein the security validation method call identifies a user identified by the security identification embedded in the Service Access Manager object 326 and a constructor right required to instantiate objects of the Service object's 322 class. In the Talon system, this validation comprises invocation of a validateSecurityAccess (security certificate, constructor right) method call that communicates the Security Certificate object 411 embedded in the Service Access Manager object 326, along with one or more required constructor rights associated with the requested service. The user identified by the Security Certificate object 411 and the constructor right(s) are checked against the one or more Access Control Lists (ACLs) 401 maintained by the Security Manager object 328. In general, an ACL contains security attributes used to perform security validation. Multiple ACLs may be maintained by the Security Manager object 328, including a user ACL and ACLs for each security entity in the security model, e.g., for each method call for which security is desired.
Assuming the user identified by the Security Certificate object 411 embedded in the Service Access Manager 326 has the required constructor rights, the Security Manager object 328 returns a new Security Certificate object 411 associated with the user identified by the Security Certificate object 411 originally passed to the Security Manager object 328. The returned Security Certificate object 411 is embedded in a new, user-specific Service object 322 instantiated by the Service Access Manager object 326. To command an operation performed by one or more methods of the Service object 322, the client may then perform an operation method call to the Service object 322 using the returned Service object reference 314 (Block 535). In response, the Service object 322 may perform the requested operation conditioned upon whether the user identified by the security identification 412 embedded therein is authorized to invoke the requested operation method (Block 540). Specifically, the Service object 322 may make a method call to the Security Manager Object 328 that identifies the user identified by the Security Certificate object 411 and a method invocation right required to perform the particular method. In the aforementioned Talon system, this is achieved with a validateSecurityAccess(certificate, service method right) call to the Security Manager object 328. In response, the Security Manager 328 checks the user identified by the Security Certificate object 411 and the required method invocation right against its ACL 401, and returns an indication of whether the user has the required right. Assuming the Security Manager object 328 returns a positive indication, the Service object 322 then performs the requested operation. Fig. 6 illustrates exemplary operations 600 for using a security-enabled Service object
322 according to an aspect of the present invention. Specifically, Fig. 6 illustrates a client 312 resident at a first computer 310. The client possesses a reference 314 to a user-specific security-enabled MyUPS object 322 that includes a user-specific Security Certificate object 411. The client performs a ShutdownUPS("now") method call to the MyUPS object 322 using the reference 314, wherein the call communicates a parameter "now" that indicates that the client 312 desires to command a UPS 330 to shut down immediately. In response, the MyUPS object 322 performs a validateSecurityAccess(certificate, "shutdown") call to the Security Manager object 328. The validateSecurityAccess (certificate, "shutdown") passes two parameters, the Security Certificate object 411 and a "shutdown" right required to perform the called method. The Security Manager object 328 checks these parameters against the ACL 401, e.g., against the set of ACLs associated with the identified user, returning an indication of whether the user associated with the Security Certificate object 411 has the required "shutdown" right.
If the Security Manager object 328 returns a positive indication, the MyUPS object 322 performs the requested method, causmg a series of operational steps to be performed in a JVM 321 and the second computer 320 needed to command the UPS 330 to shut down. Those skilled in the art will appreciate that many of these steps will be specific to the operating system and hardware of the computer 320 and/or its interface with the UPS 330. For example, control of the UPS 330 from the computer 320 may involve execution of software drivers (not shown) resident on the computer 320 that provide an interface to the UPS 330. Those skilled in the art will also appreciate that specific commands and/or command formats sent to the UPS 330 are generally specific to the UPS 330, e.g., are dependent on the make and manufacturer of the UPS 330. Details of such elements, commands and command formats are known to those skilled in the art and are not discussed in detail herein.
Fig. 6 illustrates ways in which a service object, such as the MyUPS object 322, may implement user-specific, method-level security, i.e., by performing a validation method call to the Security Manager object 328. It will be understood, however, that a service object is not required to make a security validation call for every method request it receives from a client. Rather, the systems, methods and computer program products of the present invention provide a flexible framework for selectively providing user-specific, method-level security. The exact manner in which security is provided to a service object such as the MyUPS object of Fig. 6 can be determined, for example, by the manner in which the service object is constituted, e.g., by the specific methods included in the service objects class, either directly or by inheritance from other object classes.
Fig. 7 illustrates exemplary operations 700 according to another aspect of the present invention, showing how the distributed security described above may be expanded across multiple platforms in a network. A client 312 resident at a first computer 310 possesses a reference 314a to a user-specific security-enabled MyUPS object 322a on a second computer 320a. The MyUPS object 322a includes a user-specific Security Certificate object 411, instantiated by a Security Access Manager object 326a. The client performs a MonitorUPS("battery") method call to the MyUPS object 322a using the reference 314a, wherein the call communicates a parameter "battery" that indicates that the client 312 desires to monitor the state of a battery at a UPS 330a. In response, the MyUPS object 322a performs a validateSecurityAccess(certificate, "monitor") call to the Security Manager object 328a. The validateSecurityAccess(certificate, "monitor") passes two parameters, the Security Certificate object 411 and a "monitor" right required to perform the called method. A Security Manager object 328a checks these parameters against its ACL 401a, returning an indication of whether the user associated with the Security Certificate object 411 has the required "monitor" right. If the Security Manager object 328a returns a positive indication, the MyUPS object 322a performs the requested method, causing a series of operational steps in a JVM 321a and the second computer 320a needed to return the status information from the UPS 330a to the client 312. The client 312 may use the status information so obtained to invoke operations at a third computer 320b. The client 312 also possesses a reference 314b to a user-specific security-enabled MyPage object 322b on the third computer 320a. The MyPage object 322b includes a user-specific Security Certificate object 411, instantiated by a Security Access Manager object 326b. The client 312 performs a Page("maintenance ", "message ") method call to the MyPage object 322b using the reference 314b, wherein the call communicates a parameter "maintenance" that indicates that the client 312 desires to send a "message" to maintenance personnel regarding the status of the battery at the UPS 330a. In response, the MyPage object 322b performs a validateSecurityAccess(certificate, "page") call to the Security Manager object 328b. The validateSecurityAccess(certificate, "page") call passes two parameters, the Security Certificate object 411 and a "page" right required to perform the called method. A Security Manager object 328b checks these parameters against its ACL 401b, returning an indication of whether the user associated with the Security Certificate object 411 has the required "page" right. If the Security Manager object 328b returns a positive indication, the MyPage object 322b performs the requested method, causing a series of operational steps in a JVM 321b and the third computer 320b needed to effect transmission of the page message from a modem 330b connected to the third computer 320b. It will be appreciated that the embodiments illustrated in Figs. 6 and 7 are illustrative, and that the present invention is not limited to the architectures and operations shown. For example, much more elaborate object relationships may be used with the present invention. For example, control of the UPS 330a and the modem 330b of Fig. 7 may involve the interaction of a variety of different service objects on a variety of object hierarchy levels. Security identifications, e.g., Security Certificate objects, may be propagated to these objects in many ways. Security identifications may be propagated directly from a Service Access Manager object as shown, or may be propagated from a parent service object class to subclasses of the parent service object class.
Fig. 8 illustrates exemplary distribution and maintenance of security information in a distributed object environment according to another aspect of the present invention. A security domain 800 is defined, including a plurality of Service Engine objects 830a, 830b resident on respective computers 810a, 810b, executing on respective JVMs 811a, 811b. The engine objects 830a, 830b reside at the heads of object hierarchies including Service User Validation objects 324a, 324b and Security Manager Objects 326a, 326b, including respective access control lists 410a, 401b. Also included are security-enabled Service Access Manager objects 326a, 326b and security enabled Service Objects 332a, 332b, which may be assigned to a plurality of different users recognized in the domain 800.
One of the Service Engine objects 830a serves as "domain controller," i.e., an object responsible for maintaining and distributing security information from a security database 840 that includes access information for users recognized in the domain 800. The domain controller Service Engine object 830a ensures, for example, that appropriate security information is replicated in an ACL 401b used by the Security Manager object 830b on the second computer 810b. Typically, this may occur when the second Service Engine 830b is instantiated, and intermittently during the lifetimes of the Service Engine objects 830a, 830b, for example, when user security privileges are added or removed by a system administrator invoking methods of the domain controller Service Engine 830a.
In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.

Claims

THAT WHICH IS CLAIMED IS:
1. A method of securely managing operations at a computer, the method comprising the steps of: instantiating a user- specific Service Access Manager object at the computer in response to a request for access for a user at a client, the Service Access Manager object including a first security identification specific to the user; returning a reference for the Service Access Manager object to the client; performing a service request method call requesting a service to the Service Access Manager object from the client; instantiating a user-specific Service object including a second security identification specific to the user identified in the first security identification if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class; returning a reference for the user-specific Service object to the client; performing an operation request method call to the Service object from the client, the operation request method call requesting an operation by the Service object; and conditionally performing the operation based on whether the user identified in the second security identification is authorized to invoke the operation request method.
2. A method according to Claim 1, wherein the client is resident at a second computer.
3. A method according to Claim 1 , wherein said step of instantiating a user- specific Service Access Manager object comprises the step of creating an instance of a
Service Access Manager class and encapsulating a user-specific Security Certificate object therein.
4. A method according to Claim 3, wherein said step of instantiating a user- specific Service object comprises the step of creating an instance of a Service object class and encapsulating a second Security Certificate object therein that identifies the user identified in the first Security Certificate object, if the first Security Certificate object identifies a user authorized to invoke a constructor method of the Service object's class.
5. A method according to Claim 1 , wherein said step of instantiating a user- specific Service object comprises the steps of: performing a security validation method call to a Security Manager object from the Service Access Manager object in response to the service request method call, the security validation method call communicating the first security identification and a constructor right required to instantiate an instance of the Service object's class and requesting an indication of whether the user identified by the first security identification has the required constructor right; responsively determining whether the user identified by the first security identification has the required constructor right at the Security Manager object; returning a second security identification identifying the user identified in the first security identification to the Service Access Manager object if the user identified by the first security identification has the required constructor right; and instantiating a user-specific Service object including the second security identification embedded therein.
6. A method according to Claim 5, wherein said step of conditionally performing the operation comprises the steps of: performing a second security validation method call to the Security Manager object from the Service object in response to the operation request method call, the security validation method call communicating the second security identification and a right required to invoke to the operation request method and requesting an indication of the whether the user identified by the second security identification has the required invocation right; responsively returning an indication of whether the user identified by the second security identification has the required invocation right from the Security Manager object to the Service object; and performing the requested operation if the returned indication indicates that the user identified by the second security identification has the required invocation right.
7. A method according to Claim 5: wherein said step of performing a security validation method call is preceded by the step of embedding an access control list in the Security Manager object; and wherein said step of responsively determining comprises the step of comparing the user identified in the first security identification and the required constructor right with the access control list to determine whether the user identified in the first security identification has the required constructor right.
8. A method according to Claim 6: wherein said step of performing a second security validation method call is preceded by the step of encapsulating an access control list in the Security Manager object; and wherein said step of responsively determining comprises the steps of: comparing the user identified in the second security identification and the required invocation right with the access control list to determine whether the user identified in the second security identification has the required invocation right; and returning an indication of whether the user identified by the second security identification has the required invocation right from the Security Manager object to the Service object based on the comparison.
9. A method according to Claim 8: wherein said step of encapsulating is preceded by the steps of: instantiating a Service Engine object at a first computer, the first Service Engine object operative to maintain a database of security information for a security domain; instantiating the Security Manager object at a second computer; and wherein said step of encapsulating comprises the steps of: communicating security information from the Service Engine object to the Security Manager object; and building the access control list from the communicated security information.
10. A method according to Claim 9, wherein the domain comprises a plurality of Service Engine objects.
11. A method of securely managing operations at a computer, the method comprising the steps of: instantiating a user-specific Service Access Manager object at the computer in response to an access request from a client, the Service Access Manager object including a security identification; propagating the security identification in a Service object instantiated by the Service Access Manager object in response to a request for a service communicated to the Service Access Manager object by the client; and conditioning performance of a method of the Service object called from the client based upon the propagated security identification and a method invocation right requirement associated with the method of the Service object.
12. A method according to Claim 11 , further comprising the step of conditioning instantiation of a Service object by the Service Access Manager object based upon the security identification embedded in the Service Access Manager object and a constructor right associated with the Service object's class.
13. A method according to Claim 12, wherein said step of conditioning instantiation comprises the step of validating that a user identified by the security identification embedded in the Service Access Manager object has the constructor right using a method call to a Security Manager object that is operative to maintain security information.
14. A method according to Claim 13, wherein said step of conditioning performance of a method comprises the step of validating that a user identified by the security information propagated to the Service object meets the method invocation right requirement using a method call to the Security Manager object.
15. A method according to Claim 11 , wherein the client is resident at a remote computer.
16. A method according to Claim 11 : wherein said step of instantiating a user-specific Service Access Manager object comprise the step of encapsulating a Security Certificate object in the Service Access Manager object, the Security Certificate object including the security identification; and wherein said step of propagating comprises the step of propagating the Security
Certificate object in the Service object.
17. A computing system, comprising: a computer; and a user- specific Service Access Manager object resident at said computer, the Service Access Manager object including a first security identification specific to a user at a client and operative to instantiate a Service object at the first computer responsive to a service request method call from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class.
18. A system according to Claim 17, further comprising a user-specific Service object resident at said computer, the Service object including a second security identification specific to the user identified in the first security identification, wherein the Service object is operative to conditionally perform an operation requested in an operation request method call from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method.
19. A system according to Claim 17, wherein the client is resident at a second computer.
20. A system according to Claim 18 : wherein said Service Access Manager object comprises a first Security Certificate object that provides the first security identification; and wherein said Service object comprises a second Security Certificate object that provides the second security identification.
21. A system according to Claim 18, further comprising a Security Manager Object resident at said computer and operative to maintain security information, and: wherein said Service Access Manager object is operative to perform a security validation method call to the Security Manager object in response to the service request method call, the security validation method call communicating the first security identification and a constructor right required to instantiate an instance of a Service object's class and requesting an indication of whether the user identified by the first security identification has the required constructor right; wherein said Security Manager object is operative to responsively determine whether the user identified by the first security identification has the required constructor right and to return a second security identification identifying the user identified in the first security identification to the Service Access Manager object if the user identified by the first security identification has the required constructor right, and wherein said Service Access Manager object is operative to instantiate a user-specific Service object at the computer responsive to the returned indication, the Service object including a second security identification that identifies a user identified in the first security identification.
22. A system according to Claim 21 : wherein said Service object is operative to perform a security validation method call to the Security Manager object in response to the operation request method call, the security validation method call communicating the second security identification and a right required to invoke to the operation request method and requesting an indication of the whether the user identified by the second security identification has the required invocation right; wherein said Security Manager object is operative to responsively return an indication of whether the user identified by the second security identification has the required invocation right; and wherein said Service object is operative to perform the operation if the returned indication indicates that the user identified by the second security identification has the required invocation right.
23. A system according to Claim 21 , wherein said Security Manager object comprises an access control list and is operative to check the user identified in the first security identification and the required constructor right against the access control list to determine whether the user identified in the first security identification has the required constructor right.
24. A system according to Claim 23, wherein said Security Manager object comprises an access control list and is operative to check the user identified in the second security identification and the required invocation right against the access control list to determine whether the user identified in the second security identification has the required invocation right and to responsively return an indication of whether the user identified by the second security identification has the required invocation right to the Service object based on the comparison.
25. A system according to Claim 24, wherein said Security Manager object is operative to receive security information from a Service Engine object and to build the access control list from the received security information.
26. A computer program product for securely managing operations of a computer, the computer program product comprising: a computer-readable storage medium configured to instruct a computer to perform the steps of: instantiating a user-specific Service Access Manager object including a first security identification specific to a user at the computer in response to a request for access for the user at a client; returning a reference for the Service Access Manager object to the client; instantiating a user-specific Service object including a second security identification specific to the user identified in the first security identification in response to a service request method call to the Service Access Manager object from the client if the first security identification identifies a user authorized to invoke a constructor method of the Service object's class; returning a reference for the user-specific Service object to the client; and conditionally performing an operation requested in an operation request method call to the Service object from the client based on whether the user identified in the second security identification is authorized to invoke the operation request method.
27. A computer program product according to Claim 26, wherein said step of instantiating a user-specific Service Access Manager object comprises creating an instance of a Service Access Manager class and encapsulating a user-specific Security Certificate object therein.
28. A computer program product according to Claim 27, wherein said step of instantiating a user-specific Service object comprises creating an instance of a Service object class and encapsulating a second Security Certificate object therein that identifies the user identified in the first Security Certificate object if the first Security Certificate object identifies a user authorized to invoke a constructor method of the Service object's class.
29. A computer program product according to Claim 26, wherein said computer- readable storage medium is configured to instruct the computer to instantiate a Security Manager object operative to maintain security information, and wherein said step of instantiating a user-specific Service object comprises: performing a security validation method call to the Security Manager object from the
Service Access Manager object in response to the service request method call, the security validation method call communicating the first security identification and a constructor right required to instantiate an instance of the Service object's class and requesting an indication of whether the user identified by the first security identification has the required constructor right; responsively determining whether the user identified by the first security identification has the required constructor right at the Security Manager object; returning a second security identification identifying the user identified in the first security identification to the Service Access Manager object if the user identified by the first security identification has the required constructor right; and instantiating a user-specific Service object including the second security identification.
30. A computer program product according to Claim 29, wherein said step of conditionally performing the operation comprises: performing a second security validation method call to the Security Manager object from the Service object in response to the operation request method call, the security validation method call communicating the second security identification and a right required to invoke to the operation request method and requesting an indication of the whether the user identified by the second security identification has the required invocation right; responsively returning an indication of whether the user identified by the second security identification has the required invocation right from the Security Manager object to the' Service object; and performing the requested operation if the returned indication indicates that the user identified by the second security identification has the required invocation right.
31. A computer program product according to Claim 29: wherein the computer-readable program product is operative to instruct the computer to embed an access control list in the Security Manager object before performing a security validation method call; and wherein said step of responsively determining comprises comparing the user identified in the first security identification and the required constructor right with the access control list to determine whether the user identified in the first security identification has the required constructor right.
32. A computer program product according to Claim 30: wherein the computer-readable program product is configured to instruct the computer to encapsulate an access control list in the Security Manager object before performing the second security validation method call; and wherein said step of responsively determining comprises: comparing the user identified in the second security identification and the required invocation right with the access control list to detennine whether the user identified in the second security identification has the required invocation right; and returning an indication of whether the user identified by the second security identification has the required invocation right from the Security Manager object to the Service object based on the comparison.
33. A computer program product according to Claim 32: wherein the computer-readable storage medium is configured to instruct the computer to perform the steps of: instantiating a Service Engine object at a first computer, the first Service
Engine object operative to maintain a database of security information for a security domain; instantiating the Security Manager object at a second computer; and wherein said step of encapsulating comprises: communicating security information from the Service Engine object to the
Security Manager object; and building the access control list from the communicated security information.
34. A computer program product for securely managing operations of a computer, the computer program product comprising: a computer-readable storage medium configured to instruct a computer to perform the steps of: instantiating a user-specific Service Access Manager object at the computer in response to an access request from a client, the Service Access Manager object including a security identification; propagating the security identification in a Service object instantiated by the Service Access Manager object in response to a request for a service communicated to the Service Access Manager object by the client; and conditioning performance of a method of the Service object called from the client based upon the propagated security identification and a method invocation right requirement associated with the method of the Service object.
35. A computer program product according to Claim 34, wherein the computer- readable storage medium is configured to instruct the computer to condition instantiation of a Service object by the Service Access Manager object based upon the security identification embedded in the Service Access Manager object and a constructor right associated with the Service object's class.
36. A computer program product according to Claim 35, wherein said step of conditioning instantiation comprises the step of validating that a user identified by the security identification embedded in the Service Access Manager object has the constructor right using a method call to a Security Manager object that is operative to maintain security information.
37. A computer program product according to Claim 36, wherein said step of conditioning performance of a method comprises the step of validating that a user identified by the security information propagated to the Service object meets the method invocation right requirement using a method call to the Security Manager object.
38. A computer program product according to Claim 34: wherein said step of instantiating a user-specific Service Access Manager object comprise the step of encapsulating a Security Certificate object in the Service Access Manager object, the Security Certificate object including the security identification; and wherein said step of propagating comprises the step of propagating the Security
Certificate object in the Service object.
PCT/US2000/008280 1999-04-02 2000-03-28 Apparatus, methods and computer program product for secure distributed data processing WO2000060454A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40405/00A AU4040500A (en) 1999-04-02 2000-03-28 Apparatus, methods and computer program products for secure distributed data processing using user-specific service access managers and propagated security identifications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28552399A 1999-04-02 1999-04-02
US09/285,523 1999-04-02

Publications (4)

Publication Number Publication Date
WO2000060454A2 true WO2000060454A2 (en) 2000-10-12
WO2000060454A3 WO2000060454A3 (en) 2001-02-08
WO2000060454A8 WO2000060454A8 (en) 2001-03-22
WO2000060454A9 WO2000060454A9 (en) 2001-12-06

Family

ID=23094613

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/008280 WO2000060454A2 (en) 1999-04-02 2000-03-28 Apparatus, methods and computer program product for secure distributed data processing

Country Status (2)

Country Link
AU (1) AU4040500A (en)
WO (1) WO2000060454A2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003003177A2 (en) * 2001-06-29 2003-01-09 Bea Systems, Inc. System for and methods of administration of access control to numerous resources and objects
GB2405561A (en) * 2003-08-28 2005-03-02 Motorola Inc Network security system which monitors authentication of a client to a domain controller
US7441264B2 (en) 2002-06-24 2008-10-21 International Business Machines Corporation Security objects controlling access to resources
EP2658204A1 (en) * 2012-04-27 2013-10-30 ABB Research Ltd. Access control in an industrial control system
US8701200B2 (en) 2006-10-31 2014-04-15 Microsoft Corporation Analyzing access control configurations

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0456920A2 (en) * 1989-05-15 1991-11-21 International Business Machines Corporation Remote authentication and authorisation in a distributed data processing system
US5706349A (en) * 1995-03-06 1998-01-06 International Business Machines Corporation Authenticating remote users in a distributed environment
US5875296A (en) * 1997-01-28 1999-02-23 International Business Machines Corporation Distributed file system web server user authentication with cookies

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0456920A2 (en) * 1989-05-15 1991-11-21 International Business Machines Corporation Remote authentication and authorisation in a distributed data processing system
US5706349A (en) * 1995-03-06 1998-01-06 International Business Machines Corporation Authenticating remote users in a distributed environment
US5875296A (en) * 1997-01-28 1999-02-23 International Business Machines Corporation Distributed file system web server user authentication with cookies

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GITTLER F., HOPKINS A. C.: "THE DCE SECURITY SERVICE" HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO., PALO ALTO, CA, US, vol. 46, no. 6, 1 December 1995 (1995-12-01), pages 41-48, XP000581124 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003003177A2 (en) * 2001-06-29 2003-01-09 Bea Systems, Inc. System for and methods of administration of access control to numerous resources and objects
WO2003003177A3 (en) * 2001-06-29 2003-12-18 Bea Systems Inc System for and methods of administration of access control to numerous resources and objects
US7441264B2 (en) 2002-06-24 2008-10-21 International Business Machines Corporation Security objects controlling access to resources
US7577986B2 (en) 2002-06-24 2009-08-18 International Business Machines Corporation Security objects controlling access to resources
GB2405561A (en) * 2003-08-28 2005-03-02 Motorola Inc Network security system which monitors authentication of a client to a domain controller
GB2405561B (en) * 2003-08-28 2006-07-26 Motorola Inc Computer network security system and method for preventing unauthorised access of computer network resources
US8701200B2 (en) 2006-10-31 2014-04-15 Microsoft Corporation Analyzing access control configurations
EP2658204A1 (en) * 2012-04-27 2013-10-30 ABB Research Ltd. Access control in an industrial control system

Also Published As

Publication number Publication date
WO2000060454A3 (en) 2001-02-08
AU4040500A (en) 2000-10-23
WO2000060454A8 (en) 2001-03-22
WO2000060454A9 (en) 2001-12-06

Similar Documents

Publication Publication Date Title
US6691113B1 (en) Persistent data storage for client computer software programs
US6463446B1 (en) Method and apparatus for transporting behavior in an event-based distributed system
US7707411B2 (en) Method and system for providing a trusted platform module in a hypervisor environment
Kon et al. Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB
US6931546B1 (en) System and method for providing application services with controlled access into privileged processes
Morin et al. Models@ run. time to support dynamic adaptation
Gong Secure Java class loading
US7310822B2 (en) Filtering a permission set using permission requests associated with a code assembly
US6138238A (en) Stack-based access control using code and executor identifiers
US6681243B1 (en) Network environment supporting mobile agents with permissioned access to resources
US7516477B2 (en) Method and system for ensuring that computer programs are trustworthy
US9785799B2 (en) System and method for role based analysis and access control
CN102299914B (en) For enabling the trusted intermediary accessing control of Internet statement
US6961855B1 (en) Notification of modifications to a trusted computing base
Watson et al. The trustedbsd mac framework
US20060026419A1 (en) Method, apparatus, and product for providing a scalable trusted platform module in a hypervisor environment
US8924928B1 (en) Rule-based, run-time-alterable, client-agnostic client-server system
US7389495B2 (en) Framework to facilitate Java testing in a security constrained environment
WO2000060454A2 (en) Apparatus, methods and computer program product for secure distributed data processing
GB2308688A (en) Controlling access to objects in an information handling system
Horie et al. Using meta-interfaces to support secure dynamic system reconfiguration
Welch et al. Using reflection as a mechanism for enforcing security policies in mobile code
US20160357953A1 (en) Decentralized information flow securing method and system for multilevel security and privacy domains
Herzog et al. Using the Java sandbox for resource control
Lau et al. JAVM: Internet-based Parallel Computing Using Java

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CU CZ CZ DE DE DK DK EE EE ES FI FI GB GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: C1

Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i

Free format text: PAT. BUL. 41/2000 UNDER (81) ADD "AG, CR, DM, DZ, GD, MA"; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

AK Designated states

Kind code of ref document: C2

Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/8-8/8, DRAWINGS, REPLACED BY NEW PAGES 1/9-9/9; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)