Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Security kernel or utility
Reexamination Certificate
1998-11-30
2002-05-07
Peeso, Thomas R. (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Security kernel or utility
C713S152000, C713S168000, C713S169000, C713S170000, C380S247000, C380S257000
Reexamination Certificate
active
06385724
ABSTRACT:
TECHNICAL FIELD
The present invention relates to providing security for programming objects, and more particularly relates to an object security service for providing caller identities.
BACKGROUND OF THE INVENTION
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a retail business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations.
In a server application that is used by a large number of people, it is often useful to discriminate between what different users and groups of users are able to do with the server application. For example, in an on-line bookstore server application that provides processing services for entering book orders, order cancellations, and book returns, it may serve a useful business purpose to allow any user (e.g., sales clerk or customers) to access book order entry processing services, but only some users to access order cancellation processing services (e.g., a bookstore manager) or book return processing services (e.g., returns department staff).
Network operating systems on which server applications are typically run provide sophisticated security features, such as for controlling which users can logon to use a computer system, or have permission to access particular resources of the computer system (e.g., files, system services, devices, etc.) In the Microsoft Windows NT operating system, for example, each user is assigned a user id, which has an associated password. A system administrator also can assign sets of users to user groups, and designate which users and user groups are permitted access to system objects that represent computer resources, such as files, folders, and devices. During a logon procedure, the user is required to enter the user id along with its associated password to gain access to the computer system. When the user launches a program, the Windows NT operating system associates the user id with the process in which the program is run (along with the process' threads). When a thread executing on the user's behalf then accesses a system resource, the Windows NT operating system performs an authorization check to verify that the user id associated with the thread has permission to access the resource. (See, Custer,
Inside Windows NT
22, 55-57, 74-81 and 321-326 (Microsoft Press 1993).)
A thread is the basic entity to which the operating system allocates processing time on the computer's central processing unit. A thread can execute any part of an application's code, including a part currently being executed by another thread. All threads of a process share the virtual address space, global variables, and operating-system resources of the process. (See, e.g., Tucker Jr., Allen B. (editor),
The Computer Science and Engineering Handbook
1662-1665 (CRC Press 1997).)
In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item's properties with methods (e.g., program functions or procedures) to represent the item's functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance.
Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related methods of the object. In other words, the client programs do not access the object's data directly, but must instead call methods on the object's interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
In object-oriented programming, it is common for a first object to call other objects to perform work on its behalf. These other objects are sometimes referred to as being “downstream” from the first object because the method calls figuratively flow from an upstream object (i.e., the first or caller object) to downstream objects (i.e., the other called objects). The downstream objects may reside at remote locations or run in other processes; therefore, the downstream objects may be associated with identities different from the first object. For example, a typical arrangement is to associate objects executing in certain processes with the system user. Requests for the user identity of calls from these objects will provide the identity “system.”
A problem arises when an object executed by a user calls one of the system objects to perform work for it because a call from the system object apparently originates from the system user. Therefore, the security services cannot determine which user actually initiated the original call (e.g., whether it was a manager or a customer).
For example, an application for tracking employee time at a bookstore might create a timekeeping component at startup and associate the timekeeping component with the user “system.” The timekeeping component tracks employees' hours by calling other components to write information to a log and other components to edit the log.
Subsequently, when users access the timekeeping component, it is desirable for the identity of the accessing user to be associated with the component, not the system identity. Otherwise, security checks for the writing and editing components cannot differentiate between users to determine if the user is permitted to edit the log (e.g., whether the user is a manager). Also, for auditing purposes, it is desirable to track which user performed what actions. Under the described scenarios, information about the direct caller (i.e., the “system”) is not useful. Therefore, a mechanism is needed by which a component can supply an identity other than that associated with its process when making calls to other components.
One attempted solution to this downstream object identity problem is provided by Windows NT, which supports a feature called “impersonation.” Using impersonation, a programming component can specify the identity of another, and calls from the component appear to be originating from that user. Additionally, components can specify an impersonation level, indicating whether or not they allow themselves to be impersonated.
However, impersonation under Windows NT requires logic in the component call various security application programming interfaces (or APIs), requiring application developers to become familiar with the APIs and the inner workings of the operating system's security framework. Further, the complexities of the APIs may lead to programming errors when implementing impersonation, resulting in holes in the application's security scheme or other undesired operation. Finally, each developer may use the APIs to develop a different impersonation scheme, making it considerably difficult to combine appli
Andrews Anthony D.
Armanasu Alexander A.
Beckman Brian C.
Klarquist & Sparkman, LLP
Peeso Thomas R.
LandOfFree
Automatic object caller chain with declarative impersonation... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Automatic object caller chain with declarative impersonation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automatic object caller chain with declarative impersonation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2889178