|Publication number||US7568217 B1|
|Application number||US 10/394,289|
|Publication date||Jul 28, 2009|
|Priority date||Mar 20, 2003|
|Publication number||10394289, 394289, US 7568217 B1, US 7568217B1, US-B1-7568217, US7568217 B1, US7568217B1|
|Inventors||Ranjan Prasad, Vinod Dashora|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Non-Patent Citations (7), Referenced by (47), Classifications (8), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention generally relates to managing usage and access of resources on a network. The invention relates more specifically to method and apparatus for using a role based access control system on a network.
Role based access control (RBAC) systems are gaining popularity as the methodology for choice for managing network privileges, access to network resources, and other security policies. RBAC systems assign roles to users or classes of users. Each role is defined by a class of occupants, and by actions that the class of occupants is allowed to perform in accessing and utilizing some or all of the resources on a network. Thus, in a RBAC system, the privileges (including network privileges, permissions to access protected resources, and privileges to perform actions) and authorizations of a particular user will depend on the role or roles that the user occupies.
For example, one user on a network may have only one role that corresponds to “employee”. The role of “employee” provides the user with a certain set of privileges, including use of basic network resources, or the ability to perform certain employee functions. Another user may have two roles that correspond to “employee” and “manager”. As a “manager”, the second user may have access to network resources that are not available to the user that is only an “employee”. Similarly, an “employee” who also has the role of an “administrator” may have the most privileges of anyone who can use the network.
Generally, RBAC systems are classified within four broad classes. RBAC0 systems are basic RBAC systems in which roles comprise a set of occupants and permissions. RBAC1 systems support hierarchies of roles; for example, the role Employee may include sub-roles Manager and Engineer. RBAC2 systems enforce principles of mutual exclusion or separation of duties. RBAC2 systems may provide for static mutual exclusion or dynamic mutual exclusion. RBAC3 systems combine the features of RBAC1 and RBAC2 systems.
One core concept that can be implemented through RBAC systems is separation of duties (SoD). The concept of SoD provides a security mechanism that protects a system of networked elements, including applications hosted by the networked elements, from the action of one user that is acting within that user's authorizations. For example, SoD may be used to limit the damage that one network user can cause through bad intent, negligence or oversight. To implement SoD, certain roles on the network are defined as mutually exclusive of other roles. SoD policies specify that users may not occupy roles that are mutually exclusive. A static SoD policy specifies that a user can never occupy two or more individual roles that are designated as “statically” mutually exclusive. A dynamic SoD policy specifies that a user can occupy two or more individual roles that are “dynamically” mutually exclusive, but the “dynamically” mutually exclusive roles cannot be occupied at the same time.
In past approaches, static and dynamic SoD policies are themselves defined statically. Thus, an administrator configures each role with either static SoD or dynamic SoD, and the specification does not change as an application runs. For example, an administrator may designate a set of roles that are statically mutually exclusive from one another, and another set of roles that are dynamically mutually exclusive from one another. For example, in a hypothetical business purchasing management application with SoD, given a “purchaser” role and a “purchase approver” role, one scenario provides that the administrator designates the two roles as statically exclusive, meaning that a user designated as being a “purchaser” can never be designated as a “purchase approver”. Another scenario provides that the administrator designates the two roles as being dynamically exclusive, meaning that the user can occupy both “purchaser” and “purchase approver” roles, but never at the same time.
This type of static definition for roles can become inconvenient in certain business environments. In particular, the role assignments may be too inflexible for various situations presented in a given business environment. For example, in the “purchaser” and “purchase approver” example provided above, there is no simple mechanism for enabling a user to approve his own purchase of a few dollars. The additional approval required in the static scenario, or the additional time required for the user to switch roles in the dynamic scenario, are burdensome when considering the context that what is being requested is purchase approval authority of a few dollars. A business cannot readily delegate this authority on a case-by-case basis. Specifically, a business cannot automate delegation of this authority on a case-by-case basis.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
A method and apparatus for using an RBAC system on a network is described. In particular, an embodiment describes using an RBAC system in accessing and operating resources executing on a combination of networked elements. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments are described herein according to the following outline:
1.0 GENERAL OVERVIEW
2.0 SYSTEM OVERVIEW
3.0 CONDITIONAL ROLE DESCRIPTIONS
4.0 METHOD FOR IMPLEMENTING CONDITIONAL ROLES
5.0 IMPLEMENTATION MECHANISMS—HARDWARE OVERVIEW
Embodiments of the invention provide for assigning roles to users of a network based on the occurrence of a condition during the user's session. In one embodiment, users of a particular class on a network may be assigned one or more roles based on conditions that occur during the user's interaction with the network. In another embodiment, two of the roles available on the network can be mutually assigned to a user only if a particular condition occurs during the user's network session. Otherwise, the two roles are treated as mutually exclusive, meaning that the user cannot occupy both roles at the same time.
An “administrative policy engine” refers to an engine that administers policies on a managed network. The engine includes software, hardware, firmware, or combination thereof, which executes one or more processes for administering the policies.
The term “resource” includes applications, logic, data provided on a network, as well as the handling of an operation. A protected operation involves resources for performing a network action, such as “configure router”, or an application specific action, such as “stop printer”. Other examples of a resource includes an interface on a router or a file in a file system.
A “role” refers to a class of users that are assigned a set of privileges on the network. The privileges may control or otherwise manage access of the network resources. A role is said to be “conditional” if it can be assigned to a particular user upon a condition occurring during a user's network session.
A user is said to “occupy” a role if the role has been assigned to the user.
A user is said to “mutually occupy” two roles if the user is assigned to two roles at the same time.
1.2 General Description
According to an embodiment, a method is provided for applying an RBAC system on a network. The method includes detecting that a user has initiated an operation that requires access to a resource on the network during a network session. A condition specified by the operation is identified. A determination is made, based on the condition, as to whether a role is to be assigned to the user based on detection of the condition. A privilege required to perform the operation may be defined by the conditional role assigned to the user.
In another embodiment, an operation initiated by a user is detected. A set of rules are identified, where the set of rules have been designated for the user initiating the operation. A determination is made as to whether a user can mutually occupy two roles, where one of the roles has already been assigned to the user, and another one of the roles is required to be assigned to the user in order for the user to perform the operation. The outcome of the determination is based on the set of rules. The user can perform the operation if the outcome of the determination is that the user can be assigned the second role. Absent a determination to the contrary, the two roles are treated as being mutually exclusive of one another.
In one embodiment, a user token is established at the beginning of a session. The token may contain, among other data, the roles the user occupies for that session. The roles are organized into broad categories. One set of roles may be static and last the duration of the user's session. Another set of roles may be based on actions that are performed by the user. Such roles may be dynamic and/or conditional. A user that is permitted to occupy such roles may or may not actually occupy the roles in a given session. A role occupancy determination may be based on business rules. For example, multiple sets of “mutually exclusive” roles may exist in a given user session and each such set may have associated with it business rules that determine the conditions under which the role occupancy can be granted to the user.
In another embodiment, a set of conditions is designated, where each condition may be identified from a user initiating an operation using resources available in the network. One or more roles that the user may occupy are determined by correlating one or more conditions that are identifiable from the operation with one or more roles that control access to resources on the network. Based on the one or more conditions, the determination is made as to whether the user can mutually occupy a first role that is assigned to user prior to the user initiating the operation, and a second role required to perform the operation. Unless the one or more conditions occur, the two roles are mutually exclusive of one another. In other words, the user can occupy either one or the other role, unless the one or more conditions occur, in which case both roles can be occupied at the same time.
Embodiments of the invention enable roles to be assigned to users on an operation-by-operation basis. A network administrator or other appropriate user may configure specific instances or conditions when a particular role is to be assigned to a user. The result is that roles can be assigned to users dynamically. The assignment of roles may be set based on the specifications and configurations of the administrators of the network. Furthermore, the roles may be assigned after the user starts a network session. For instance, the user may “switch” to administrator mode for a short duration to perform some administrative tasks and then revert back to “user roles” without having to logout and login again
Moreover, roles that are designated to be mutually exclusive of one another may be dynamically assigned to the same user for select operations. In other words, mutually exclusive roles do not have to be statically configured to be exclusive of one another. Rather, mutually exclusive roles may be assigned to the same user in order to create more flexibility in the manner SoD security policies are implemented on a network.
The RBAC system may be implemented to manage privileges of users of the network 105. In particular, the RBAC system may be implemented to select classes of users that are permitted to access and/or use certain resources on the network. In the example provided by
The policy engine 110 manages access and/or use of resources on the network by assigning roles to classes of users on the network 105. The roles govern the access and/or use of the network resources by the users. For example, access and/or use of the administrative resources may be regulated for a class of users that are designated the role of “administrator”. In one embodiment, policy engine 110 is independent of application 120 and database 122 and its functions are invoked by the application or database using an API, remote procedure call, remote method invocation, or other calling mechanism. In other embodiments, policy engine 110 may be integrated into application 120 or database 122.
When a user initiates a network session, the user is authenticated. Under one authentication scheme, the user is authenticated using a login or user-identification, and usually a password. Once authentication is complete, a session object 132 is created that specifies the authorizations or privileges of the user. The session object 132 identifies the roles assigned to the user for the particular session. The privileges defined by the roles determine what resources the user is permitted to access and/or use. Thus, roles may be determined dynamically at runtime using the session object 132, rather than statically as in prior approaches.
In an example shown by
The roles assigned to the user in the session object 132 determine the user's access to specific resources on the network 105. Specific examples of how roles may be applied are provided in the Appendix. For example, the user may not be given access to certain applications if the user is not an “administrator.” According to an embodiment, the user's ability to perform certain operations also depends on what roles the user occupies. For example, application 120 may correspond to an administrative application for managing business purchases. In that scenario, if the user wants to perform operations using application 120, the session object 132 may need to identify “administrator” as one of the roles that the user occupies in order for the use to be able to perform the operation.
According to an embodiment, the roles that the user may occupy during the network session, and that are identified in session object 132, are conditionally assignable to the user. In particular, a role may be assigned to the user in response to the user initiating one or more actions or operations. In an embodiment such as illustrated by
In an embodiment, certain roles may be conditional in that they are designated as mutually exclusive of another role, unless a condition occurs. Once the condition occurs, a user may occupy both of the otherwise mutually exclusive roles. In an embodiment described by
In this arrangement, the condition may correspond to a feature or object of an action or operation initiated by the user during the user's session. For example, for a user to complete a particular operation, the user may be required to occupy the conditionally exclusive role 140. In one embodiment, if the particular operation contains a designated condition, the user is permitted to occupy both the second role 136 and the conditionally exclusive role 140. Once the user occupies the conditionally exclusive role 140, the policy engine 110 enables the user to complete the operation. For example, policy engine 110 informs application 120 or database 122 that the user may complete the operation. Alternatively, the policy engine 110 responds to an application query of whether the user can perform a task. For example, the policy engine 110 may answer that a particular user can perform a stated task in response to an application query asking whether the user should be permitted to perform the stated task. Still further, policy engine 110 enables the user to perform some other action or operation that was previously not possible without the assignment of the conditionally exclusive role 140.
Several mechanisms and techniques may be used to assign a conditional role to the user in response to the user initiating a corresponding operation. In one embodiment, one or more roles are dynamically assigned to users at run-time. For example, roles are assigned to the user after the user has logged in and begun interacting with the network, at the same time or after session object 132 is created.
In one approach, when the user is engaged in a network session, the user may send a message, call or other communication 152 to policy engine 110. Alternatively, the user may send the communication 152 to application 120 or database 122. The communication 152 may correspond to a request or initiation to perform an operation that accesses or uses application 120, database 122, or other network resources. The communication 152 may be directed or forwarded to policy engine 110 in order to determine whether the user can perform the requested operation (by being assigned a corresponding one of the conditionally assignable roles). For example, communication 152 may be directed to policy engine 110 through intermediate network components of network 105. Alternatively, the application 120 or database 122 may redirect the communication 152 to the policy engine 110 in order to determine whether the particular user is allowed to perform the requested operation.
The policy engine 110 evaluates the communication 152 in order to detect one or more designated conditions. In an embodiment, the designated conditions may be in the form of data or objects that are contained within the initiation of the operation. Alternatively, communication 152 may identify the operation that the user is requesting, and may provide one or more attribute values from which the designated conditions may be inferred.
In an embodiment, if a designated condition is detected, the policy engine 110 matches the condition to one or more business rules 162. In one embodiment, a rule processor 155 manages business rules 162 and correlates a set of business rules to the identified conditions. In one embodiment, the rule processor 155 and the business rules 162 are part of the policy engine 110. The policy engine 110 and/or rule processor 155 evaluate the business rules 162 in order to identify one or more rules that correlate to the identified condition. The policy engine 110 then identifies what new or additional role is to be assigned to the user based on evaluating the identified business rules. The ability of the user to perform the operation specified by the communication 152 depends on what role is assigned to the user as a result of the designated condition occurring. In the example provided, the user is assigned the conditionally exclusive role 140 despite already having been assigned the second role 136. An operation requiring privileges of the conditionally exclusive role 140 can then be performed.
In an embodiment, the set of rules 162 is configured by users and vendors of the network 105. The individual rules may be defined by a condition, and a set of privileges and/or permissible actions that define or distinguish a class of the network users. The set of rules 162 may be configured, modified, and developed at design-time. In this context, design-time is any time before rules 162 are used or evaluated for purposes of determining which rules apply to a user.
If the user is assigned a role that permits performance of operation 152, an instruction may be sent from the policy engine 110 to enable an application to allow the user to perform an operation. This instruction may be sent in response to a request from that application. The terminal 104 may use the token 115 for subsequent access to application 120 (or database 122). Alternatively, the policy engine 110 may configure or instruct the application 120 or database 122 to provide access or otherwise enable the operation 152. An example of how a token may be constructed is provided in the Appendix.
In another embodiment, the dynamic assignment of roles that a particular class of user may occupy may be designated at design-time. Instructions specifying the possible roles, as well as the conditions that may trigger the possible roles to be assigned to the user during a network session, may be configured prior to users initiating network sessions. The instructions may be distributed from policy engine 110 to other network management components, applications that implement SoD policies, or to the user's terminal 104. For example, a policy server that maintains the session object 132 of a particular user may also be provided with instructions that specify all of the possible roles that the user may occupy, as well as the conditions in which particular roles are to be assigned.
According to certain embodiments, one or more roles can be dynamically defined for individuals in a particular class of users based on the occurrence of one or more designated conditions. Such dynamically defined roles are said to be conditionally assignable, in that the roles are assigned to individuals in a particular class when a designated condition occurs. The designated conditions that affect the assignment of a conditionally assignable role may include events that occur when a user initiates or attempts to perform an operation. The performance or completion of such an operation may require a new privilege to be provided to the user by the conditionally assignable role. The user, or an associated application or resource, may be permitted or enabled to complete the operation when the user is assigned the conditional role. Otherwise, the user is precluded from performing the operation.
One or more intermediate roles 220 may be assigned to subsets of users that occupy the primary role 210. In the example provided, each user that is a member of one of the intermediate roles 220 is also a member of the primary role 210. Thus, each user that is a member of one of the intermediate roles 220 has the privileges of a member in the primary role 210, and additional privileges defined for that intermediate role 220. For this reason, the intermediate roles 220 are said to have a higher hierarchical level than the primary role 210. To further the example provided, the intermediate roles may correspond to users of the role “manager”. The users of the role “manager” also belong to the class for the role of “employee”, but not all occupants of the “employee” role also occupy the “manager” role.
Additional hierarchical roles may be defined. For example, a highest level role 230 may correspond to an “administrator” who has unlimited access to the network resources. Thus, the occupant of the “administrator” role may have privileges of the “manager” role and of the “employee” role. Countless other variations of different roles and applications to classes of users are possible.
In this context, an embodiment provides for designating conditionally assignable roles to a class of users based on operations that are initiated or performed by those users.
To provide an example, the conditional role 240 may correspond to a class of users termed “purchasers”. An “employee” may submit a purchase order if the “employee” is also assigned the role of “purchaser”. According to an embodiment such as described in
In an example provided by
To provide an example, a user of a particular class (e.g. “employee”) may also be assigned the first role 270, which corresponds to “purchaser”. The role of “purchaser” may be mutually exclusive of the role of “purchase approver”, which corresponds to the second role 280. This type of separation of duties provides some security in that it precludes an employee from approving his own purchases. According to an embodiment, the mutual exclusivity of the “purchaser” and “purchase approver” roles may be removed if a designated condition occurs. For example, the designated condition may correspond to submitting a purchase order that requests the purchase of an item that is less than $50. When that happens, the person assigned the “purchaser” role may also be assigned the “purchase approver” role so that he can approve his own purchase. Thus, while there is benefit in ensuring that duties and privileges of “purchaser” and “purchase approver” are separated, there is also benefit in removing the separation of duties requirements for the two roles in certain conditions, such as when the purchase amount is below a certain threshold. One of the business rules 162 may express the foregoing condition and result.
With embodiments described herein, the particular condition that triggers the conditional assignment of a role may be provided through use of business rules. For example, a business rule may trigger the assignment of the conditional role 240 in
As described with
In step 310, business rules are defined that designate conditional roles. Each business rule may specify one or more conditions that trigger execution of the rule, and the conditional role (or roles) that are assigned to a user when the specified conditions are detected. In addition, each business rule may specify the actions, operations and/or privileges that are provided to a user who is assigned the specified role.
In an embodiment, step 310 is performed at design-time. At design-time, all business rules may be specified, and associations between business rules and conditional roles may be made. The conditions that trigger select business rules are also specified at design time.
Later, a user may login and establish a session. Alternatively, a user may request a protected resource, in which case the user may be prompted to login.
When a user is logged in, step 320 provides that an operation initiated by a user that requires assignment of a conditional role is detected. In an RBAC system, a user may specify an object or data structure when initiating performance of an operation. For example, a user that is an “employee” may submit a purchase order as an attempted operation, and the purchase order submission may not be completed unless the user is also assigned the “purchaser” role. The “purchaser” role may be conditionally assigned to the particular user.
Initiation of the operation may correspond to a request to perform the operation, or even partial performance of the operation. The policy engine 110 may detect the user initiating the operation through various mechanisms. For example, the resource that is the subject of the user's operation may request from the policy engine 110 whether the user can perform the stated operation. Completion of the operation may depend on the response from the policy engine 110, which will be based on determination of role assignments. In another embodiment, the user's terminal 104 may forward a request to perform the operation to policy engine 110. Alternatively, the resource that is being accessed or used may forward the user's request to policy engine 110. Still further, one or more intermediate management components may forward the user's request to perform the operation.
Step 330 provides that a condition is identified from the operation that permits the assignment of the conditional role to the user. Alternatively, the role assignment conditions and rules may be in the session object or the token. In an embodiment, the condition may be a data object identified in the attempted operation. In the example provided, submission of the purchase order may correspond to the occurrence of the condition.
In step 340, any business rules that correlate to the identified condition are identified. The rule processor 155 may be used to determine which, if any, of the business rules correlate to the identified condition.
Step 350 provides that the conditional assignment of roles is determined from the identified business rules. In one embodiment, a role is conditionally assignable to the user only if a corresponding condition is identified from the user initiating the operation. In another embodiment, the conditional role that is to be assigned to the user is one that is otherwise mutually exclusive of another role that the user is occupying when initiating the operation. The occurrence of the condition enables the user to mutually occupy the two roles at one time, even though the two roles are mutually exclusive of one another absent the condition occurring.
Step 360 provides that the identified conditional role is assigned to the user. In one embodiment, the user can complete the operation that triggered the assignment only upon the conditional role being assigned. The conditional role may be unassigned once the triggering operation is completed. The assignment may be in effect as long as the condition is true. In another embodiment, the user is assigned the conditional role for one or more subsequent actions or operations.
In addition to examples provided above, some applications for an embodiment such as described in
Another example is where two roles are conditionally mutually exclusive. For example, in order to implement SoD amongst administrators, a first administrator role may be the only role that permits a class of administrators to access archive records, and a second administrator role may permit another class of administrators to access personnel records, but not archives. The first administrator role and the second administrative role may be conditionally mutually exclusive of one another. For example, a member in the class of the first administrator role may not be assigned the second administrator role unless the member initiates an operation to access his own personnel records. The second administrator role may be assigned to the member of the first administrator role upon that member initiating an operation to read his personnel record. The duration in which the second administrator role is assigned to that member may be the duration until the triggering operation is completed.
Likewise, a member of the class of the second administrator role may be excluded from the first administrator role unless that member attempts an operation to access his own archive records. Upon such a condition occurring (a member of the class of the second administrative role requesting access to his own archives), the member of the class of the second administrative role is also assigned the first administrative role for purpose of completing the operation to access his own archives. The member may be re-assigned out of the first administrative role upon completing the operation.
As indicated in
Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (“CRT”), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, trackball, stylus, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 400 for using an RBAC system on a network. According to one embodiment of the invention, a method for using an RBAC system on a network is provided by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another computer-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.
Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (“ISDN”) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (“LAN”) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 420 typically provides data communication through one or more networks to other data devices. For example, network link 420 may provide a connection through local network 422 to a host computer 424 or to data equipment operated by an Internet Service Provider (“ISP”) 426. ISP 426 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet” 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 420 and through communication interface 418, which carry the digital data to and from computer system 400, are exemplary forms of carrier waves transporting the information.
Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418. In accordance with the invention, one such downloaded application provides for using an RBAC system on a network as described herein.
The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution. In this manner, computer system 400 may obtain application code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5911143 *||Aug 14, 1995||Jun 8, 1999||International Business Machines Corporation||Method and system for advanced role-based access control in distributed and centralized computer systems|
|US6453353 *||Feb 12, 1999||Sep 17, 2002||Entrust, Inc.||Role-based navigation of information resources|
|US6460141 *||Oct 28, 1998||Oct 1, 2002||Rsa Security Inc.||Security and access management system for web-enabled and non-web-enabled applications and content on a computer network|
|US20030037263 *||Aug 8, 2002||Feb 20, 2003||Trivium Systems Inc.||Dynamic rules-based secure data access system for business computer platforms|
|US20040162905 *||Feb 14, 2003||Aug 19, 2004||Griffin Philip B.||Method for role and resource policy management optimization|
|1||*||Botha et al. Separation of duties for access control enforcement in workflow environments 2001 IBM Systems Journal vol. 40, No. 3 pp. 666-682.|
|2||Brian Kropp, et al., "Case Study, Access to Cost Savings," Information Security, Apr. 2001, http://www.infosecuritymag.com/articles/april01/cover.shtml#case-study, printed Jul. 14, 2003, pp. 9-12.|
|3||*||D. Richard Kuhn Mutual Exclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems Second ACM Workshop on Role Based Access Control, 1997.|
|4||David F. Ferraiolo, et al., "Proposed NIST Standard for Role-Based Access Control," Aug. 2001, ACM Transactions on Information and System Security, vol. 4, No. 3, pp. 224-274.|
|5||*||Ferraiolo, David F., John F. Barkley and D. Richard Kuhn "A role-based access control model and reference implementation within a corporate intranet" ACM Transactions on Information and System Security vol. 2, No. 1 pp. 34-64, 1999.|
|6||Gail-Joon Ahn, et al., "The RSL99 Language for Role-Based Separation of Duty Constraints," 1999, ACM, pp. 43-54.|
|7||*||Oh et al. Task-Role Based Access Control (T-RBAC): An Improved Access Control Model for Enterprise Environment 2000 Springer-Verlag Berlin Heidelberg DEXA 2000, LNCS 1873 pp. 264-273.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8126750 *||Apr 27, 2006||Feb 28, 2012||Microsoft Corporation||Consolidating data source queries for multidimensional scorecards|
|US8136147 *||Apr 16, 2007||Mar 13, 2012||International Business Machines Corporation||Privilege management|
|US8190992||Apr 21, 2006||May 29, 2012||Microsoft Corporation||Grouping and display of logically defined reports|
|US8261181||Mar 30, 2006||Sep 4, 2012||Microsoft Corporation||Multidimensional metrics-based annotation|
|US8321805||Jan 30, 2007||Nov 27, 2012||Microsoft Corporation||Service architecture based metric views|
|US8365263 *||Jan 29, 2013||Siemens Aktiengesellschaft||Method for managing usage authorizations in a data processing network and a data processing network|
|US8365275 *||Jan 29, 2013||Ricoh Company, Ltd.||Image processing apparatus, session managing method and session managing program|
|US8495663||Feb 2, 2007||Jul 23, 2013||Microsoft Corporation||Real time collaboration using embedded data visualizations|
|US8543607 *||Aug 22, 2008||Sep 24, 2013||International Business Machines Corporation||System and method for role based analysis and access control|
|US8578444||Jun 14, 2012||Nov 5, 2013||Info Express, Inc.||Systems and methods of controlling network access|
|US8611927||Mar 31, 2011||Dec 17, 2013||Locator Ip, Lp||Interactive advisory system|
|US8634814||Feb 23, 2007||Jan 21, 2014||Locator IP, L.P.||Interactive advisory system for prioritizing content|
|US8650610||Jun 14, 2012||Feb 11, 2014||Infoexpress, Inc.||Systems and methods of controlling network access|
|US8677450||Jun 14, 2012||Mar 18, 2014||Infoexpress, Inc.||Systems and methods of controlling network access|
|US8832121||Feb 1, 2006||Sep 9, 2014||Accuweather, Inc.||Location-based data communications system and method|
|US8909679||Oct 14, 2004||Dec 9, 2014||Locator Ip, Lp||Interactive advisory system|
|US8973155 *||Mar 1, 2010||Mar 3, 2015||Nec Corporation||License management system, license management method and license management program|
|US9020885 *||May 25, 2012||Apr 28, 2015||Oracle International Corporation||Systems and methods for collaboration shared state management|
|US9058307||Jan 26, 2007||Jun 16, 2015||Microsoft Technology Licensing, Llc||Presentation generation using scorecard elements|
|US9077686 *||Mar 14, 2011||Jul 7, 2015||Oracle International Corporation||Techniques for secure transparent switching between modes of a virtual private network (VPN)|
|US9094798||Dec 12, 2014||Jul 28, 2015||Locator IP, L.P.||Interactive advisory system|
|US9191445||Jan 16, 2013||Nov 17, 2015||Giovanni Morelli||Systems and methods for managing emulation sessions|
|US9191776||Jan 15, 2014||Nov 17, 2015||Locator Ip, Lp||Interactive advisory system|
|US9197990||Jan 15, 2014||Nov 24, 2015||Locator Ip, Lp||Interactive advisory system|
|US9204252||Jul 2, 2014||Dec 1, 2015||Locator IP, L.P.||Interactive advisory system|
|US9210541||Nov 1, 2013||Dec 8, 2015||Locator IP, L.P.||Interactive advisory system|
|US9215554||Nov 1, 2013||Dec 15, 2015||Locator IP, L.P.||Interactive advisory system|
|US9237416||Dec 3, 2013||Jan 12, 2016||Locator IP, L.P.||Interactive advisory system for prioritizing content|
|US20060161469 *||Jan 14, 2005||Jul 20, 2006||Weatherbank, Inc.||Interactive advisory system|
|US20080172629 *||Jan 17, 2007||Jul 17, 2008||Microsoft Corporation||Geometric Performance Metric Data Rendering|
|US20080256606 *||Apr 16, 2007||Oct 16, 2008||George Mathew Koikara||Method and Apparatus for Privilege Management|
|US20080306958 *||Aug 22, 2008||Dec 11, 2008||Vugranam Chakravarthy Sreedhar||System and method for role based analysis and access control|
|US20090077659 *||Sep 12, 2008||Mar 19, 2009||Ricoh Company, Ltd.||Image processing apparatus, session managing method and session managing program|
|US20090158421 *||Sep 12, 2006||Jun 18, 2009||Q Software Global Limited||Security Analysis Method|
|US20090183228 *||Jul 16, 2009||Thomas Dasch||Method for managing usage authorizations in a data processing network and a data processing network|
|US20100229231 *||Sep 9, 2010||Kanako Iwai||License management system, license management method and license management program|
|US20100292996 *||Nov 18, 2010||Margrett Stephen A||Apparatus and method for enhanced client relationship management|
|US20110023082 *||Jul 23, 2009||Jan 27, 2011||Oracle International Corporation||Techniques for enforcing application environment based security policies using role based access control|
|US20110093507 *||Jun 8, 2010||Apr 21, 2011||Michael Pilip||Dynamic assignment of rights|
|US20110167480 *||Jul 7, 2011||Novell, Inc.||Techniques for secure transparent switching between modes of a virtual private network (vpn)|
|US20110230204 *||Sep 22, 2011||Locator Ip, Lp||Interactive advisory system|
|US20120239753 *||May 25, 2012||Sep 20, 2012||Oracle International Corporation||Systems and methods for collaboration shared state management|
|US20130185774 *||Jan 16, 2013||Jul 18, 2013||Sphere 3D Inc.||Systems and Methods of Managing Access to Remote Resources|
|US20130333025 *||Aug 14, 2013||Dec 12, 2013||International Business Machines Corporation||System and method for role based analysis and access control|
|US20140279059 *||Mar 14, 2013||Sep 18, 2014||Stephen A. Margrett||Apparatus and method for enhanced client communication|
|WO2011048549A2 *||Oct 19, 2010||Apr 28, 2011||Michael Pilip||Dynamic assignment of rights|
|WO2011048549A3 *||Oct 19, 2010||Oct 27, 2011||Michael Pilip||Dynamic assignment of rights|
|Cooperative Classification||H04L67/14, G06F21/6218, H04L63/102, H04L63/20|
|European Classification||G06F21/62B, H04L63/10B|