Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-11-18
2001-03-13
Kulik, Paul V. (Department: 2777)
Data processing: database and file management or data structures
Database design
Data structure types
C713S152000
Reexamination Certificate
active
06202066
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to improvements in control of access to resources or objects within a computer system, that is, by incorporation of novel object access type control techniques.
BACKGROUND OF THE INVENTION
In many circumstances it is desired to restrict access to various objects, such as files, within a computer system. In the simplest example of access control, only certain persons are permitted to read the contents of a sensitive file. In a more general statement, “objects” may also include resources, such as peripheral devices, external devices controlled by the computer system (e.g., weapons, devices controlling physical access to secured locations, and the like), as well as files or groups of files, such as directories. Further, there are varying levels of “access”; for example, in many cases, it is desired that certain individuals may only read a file, but may not alter or delete it, while others have more general “permissions” with respect to that file.
The issue of access control to objects within a computer system also arises in systems of significantly varying configuration, and operated according to widely differing mechanisms. For example, local area networks typically comprise a number of individual processor devices, i.e. personal computers or “PCs”, linked such that all share certain resources, such as a file server. Such networks are commonly operated under control of an “operating system”, which may include the capability to provide varying individuals with varying “permissions” with respect to objects stored on the file server. For example, Microsoft Corporation's “Windows NT” operating system provides this capability, by associating an “access control list” (“ACL”) (this being an example of an “access control specification”, as the latter term is used in the art) with each “object”, e.g., with each controlled file or group of files, i.e., with a directory of controlled files. Windows NT allows various permissions to be associated by the ACL with individuals or groups of individuals, so that the access sought is permitted only if the user's identification matches the a user entry in the ACL or the user is a member of a group entry in the ACL, and the user or group entry is associated with permissions for the access sought.
The issue of access control also arises in connection with relational databases, which may be accessed from a variety of processors not necessarily connected in a network operated by a single operating system per se; access control lists are then typically associated with portions of the database and operated similarly.
The question of access control also arises in connection with objects stored such that they can be accessed over the “Internet” or “Web”, i.e., such that they can be located by universal resource locator (“URL”) inquiries; the “servers” storing the resources sought may similarly store ACLs for restricting access to various objects to individuals or groups of individuals.
Stated more generally, therefore, access control mechanisms, e.g., as effectively defined by an operating system such as Windows NT, require that security attributes be maintained concerning both users and objects. User security attributes may consist of defined groups (“roles”) to which the user belongs, wherein access to various objects is permitted to all of the individuals identified as members of the group; this technique, which simplifies the assignment of permissions to users with respect to various objects by assigning various individuals to groups according to their status, is commonly referred to as “Role-Based Access Control” (“RBAC”); see co-pending Ser. No. 08/980,908, of one of the present inventors, incorporated herein by this reference.
Object security attributes generally consist of the permissions required to perform operations on the object. Access control mechanisms provided by the computer system—again, which terminology includes relational databases and the Web as well as local area networks and the like—compare user security attributes and object security attributes in order to determine access.
In each of the typical types of computer systems discussed above, object security attributes are usually kept with the object (e.g., in the header of a file) and the object resides in (or a resource is accessed through) a single server. Consequently, when an object is accessed, its security attributes can be conveniently evaluated once the object has been located. Furthermore, changes in object security attributes—e.g., to add or subtract an individual from those having access of a specified type to a particular object—need only be made at a single location.
Administering users' access to resources is often accomplished by directly associating users with permissions, that is, by providing an ACL with respect to each object or, at best, groups of objects already organized in some known way, i.e., as files within a directory. This approach can be particularly difficult, error-prone, and costly to administer when users enter and leave an organization and when users' responsibilities change within an organization, because each ACL must then be correctly altered. Comparable difficulties arise in connection with changes involving the control of access to a relational database, wherein the resources are equivalent to tables, and the access control information amounts to a list of operations that each individual (or role member) may perform.
As noted above, user access control mechanisms have been designed to address these problems and simplify the process of effectuating changes in the status of individuals and objects by the use of “roles”, whereby individuals may be organized conveniently into groups, such that each member of a particular groups is accorded the same set of permissions with respect to a group of associated objects. In effect, such Role Based Access Control (RBAC) mechanisms provide a mechanism whereby individuals may be assigned to groups; the group is then listed on an Access Control List (ACL) associated with an object or group of objects.
The central notion of Role-Based Access Control (RBAC) is that users do not have discretionary access to enterprise objects. Instead, access permissions are administratively associated with roles, and users are administratively made members of appropriate roles. This idea greatly simplifies management of authorization while providing an opportunity for great flexibility in specifying and enforcing enterprise-specific protection policies. Users can be made members of roles as determined by their responsibilities and qualifications and can be easily reassigned from one role to another without modifying the underlying access structure. Roles can be granted new permissions as new applications and actions are incorporated, and permissions can be revoked from roles as needed. Furthermore, most RBAC mechanisms support the idea of heirarchical groups, i.e., where a member of “manager”, for example, automatically obtains all permissions provided to “subordinate”.
By comparison, the basic idea of conventional ACLs is to associate an object (or group of objects, such as a “directory” of “files”, in Windows parlance) with a list of users and groups. Associated with each user or group in an ACL for an object is a set of operations which may be performed on that object. An operation on the object may be performed by a user if that user or a group to which that user belongs is listed in the ACL associated with the object and that operation is associated with that user or group. Windows NT is one well-known operating system which supports such ACL mechanisms. However, while as noted Windows NT does allow assignment of groups to ACLs, heirarchical permissions are not supported. “PASC P1003.le” is an IEEE specification for an operating system interface which similarly supports ACLs.
Adding implementation of RBAC provides several advantages over simply controlling access to objects by ACLs. Even a very simple RBAC model affords an administrator the opportunity to ex
Barkley John
Cincotta Anthony V.
Angeli Michael de
Kulik Paul V.
The United States of America as represented by the Secretary of
LandOfFree
Implementation of role/group permission association using... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Implementation of role/group permission association using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Implementation of role/group permission association using... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2472938