Role-based access control modeling and auditing system
A role-based access control (RBAC) modeling and auditing system is described that enables a user to access and/or create security roles that can be applied to users of a first software application. When a security role having a particular set of permissions has been accessed or created, the system can present a simulated user interface (UI) that indicates information that can be viewed and/or actions that can be performed by a user to whom the security role has been assigned when interacting with the first software application. The system may further provide "run as" functionality that enables a simulated UI to be generated for a particular user and that can display the security role(s) associated with the particular user. The system may be embodied in a second software application, such as a tool that is associated with the first software application.
BACKGROUND
In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. RBAC is currently used by many enterprises. In accordance with an RBAC scheme, security roles are created for various job functions within an organization. Permissions to view certain information and perform certain actions are associated with specific security roles. Employees or other system users are assigned particular security roles, and through such assignments acquire the permissions associated with those roles. Since users are not assigned permissions directly, but only acquire them through their security role (or roles), management of individual user rights becomes a matter of simply assigning appropriate security roles to the user's account. This simplifies common operations, such as adding a user, changing a user's department, or the like.
Software applications exist that allow a user to view information and perform actions by interacting with a user interface (UI), where the information that can be viewed and the actions that can be performed depend upon the security role(s) currently assigned to the user in accordance with an RBAC scheme. By way of example, SYSTEM CENTER 2012 CONFIGURATION MANAGER, published by Microsoft Corporation of Redmond Wash., is a systems management software product that enables an administrator to access and create various security roles having different sets of permissions and to assign one or more of these security roles to a user. When such user logs into SYSTEM CENTER 2012 CONFIGURATION MANAGER, he is presented with an administrative console UI that enables him to view only that information and perform only those actions that are authorized for his assigned security role(s). However, this is only one example, and other software applications exist that determine the information that can be viewed and/or the actions that can be performed by a user via a UI based on one or more security roles assigned thereto.
When an administrator interacts with a software application such as was described in the preceding paragraph to access or create a security role, such administrator may have a difficult time determining what information and actions will be made accessible via the application UI for the security role. This may be the case, for example, where there is a complex relationship between the permissions that can be assigned to the security roles and the information/actions that become accessible via the UI as a result of assigning such permissions. This may also be the case, for example, where the number of different operations that may be associated with each security role is very large.
Conventionally, one way that an administrator can determine what information can be viewed and what actions can be performed by a particular security role or combination of security roles via the UI is to create an actual user account, assign the particular security role(s) to the user associated with the user account, and then log on to the application as the user to see what information can be viewed and what actions can be performed via the application UI. However, this approach is extremely inefficient, cumbersome, and time consuming.
In certain software applications that support RBAC, it may not be easy for an administrator to determine which security roles have been assigned to a particular user. For example, such a software application may enable one or more security roles to be assigned to a user group that includes the particular user, but may display only the association between the security role(s) and the user group. Furthermore, an administrator may have a difficult time determining what information and actions will be made accessible to a particular user via the application UI based on the user's assigned security role(s). One way to obtain such information would be for the administrator to log on to the application as the user. However, such log on procedure typically requires entry of a password that is known only to the user and is therefore not accessible to the administrator. Furthermore, such an approach is extremely inefficient, cumbersome and time consuming
SUMMARY
Systems, methods and computer program products are described herein that enable a user to access or create security roles that can be applied to users of a first software application in accordance with a role based access control (RBAC) scheme. When a security role having a particular set of permissions is accessed or created, a simulated user interface (UI) may be presented that indicates one or more of information that can be viewed by a user to whom the security role has been assigned when interacting with the first software application and one or more actions that can be performed by the user to whom the security role has been assigned when interacting with the first software application. The security role accessing/creating and UI simulation features may be performed by a second software application, such as a tool, that is different from the first software application.
Systems, methods are also described herein that enable a first user to identify a second user of the first software application. Based on one or more security roles that have been associated with the second user in accordance with an RBAC scheme, a simulated UI may be presented that indicates one or more of information that can be viewed by the second user when interacting with the first software application and one or more actions that can be performed by the second user when interacting with the first software application. The security role(s) associated with the user may also be presented. The identification of the second user, UI simulation, and presentation of the security role(s) may be performed by a second software application, such as a tool, that is different from the first software application.
Some particular embodiments will now be described by way of example and without limitation. For example, a computer-implemented method is described herein. In accordance with the method, one or more first user interface elements are presented that allow a user to access or create a first security role, the first security role having one or more permissions associated therewith. Subsequent to the user accessing or creating the first security role via the one or more first user interface elements, one or more second user interface elements are presented. The one or more second user interface elements indicate at least one of: information that can be viewed by a user to whom the first security role has been assigned when the user to whom the first security role has been assigned interacts with a first software application, and one or more actions that can be performed by the user to whom the first security role has been assigned when the user to whom the first security role has been assigned interacts with the first software application. In certain embodiments, the one or more second user interface elements are presented concurrently with the one or more first user interface elements.
In accordance with the foregoing method, presenting the one or more first user interface elements may include presenting one or more user interface elements that allow the user to select the first security role from among a plurality of predefined security roles and/or that allows the user to select the one or more permissions associated with the first security role.
In one embodiment of the method, presenting the one or more first user interface elements includes presenting one or more user interface elements that further allow the user to access or create a second security role having at least one permission associated therewith that is not associated with the first security role. In accordance with such an embodiment, the method may further include modifying the one or more second user interface elements such that the one or more second user interface elements indicate at least one of: information that can be viewed by a user to whom the second security role has been assigned when the user to whom the second security role has been assigned interacts with the first software application, and one or more actions that can be performed by the user to whom the second security role has been assigned when the user to whom the second security role has been assigned interacts with the first software application.
In another embodiment, the method further includes determining that the user has one or more required permissions, and performing the presenting steps only if a determination is made that the user has the one or more required permissions.
In a further embodiment, the method steps are performed by a second software application that is different than the first software application. The second software application may comprise, for example, a tool within a toolkit associated with the first software application. In accordance with such an embodiment, the second software application may obtain configuration data stored in a database associated with the first software application. The configuration data may include at least one or more permissions that may be associated with a security role, and for each of the one or more permissions, one or more of information viewable by a user having the permission and one or more actions performable by a user having the permission. Such configuration data may be cached by the second software application. The second software application may then use the configuration data to generate at least one of the one or more first user interface elements and the one or more second user interface elements.
A system is also described herein. The system includes one or more processors and a storage medium that stores computer program logic that is executable by the one or more processors. The computer program logic includes first computer program logic and second computer program logic. The first computer program logic is programmed to cause the one or more processors to present one or more first user interface elements that allow a user to access or create a first security role, the first security role having one or more permissions associated therewith. The second computer program logic is programmed to cause the one or more processors to present one or more second user interface elements concurrently with the one or more first user interface elements. The one or more second user interface elements indicate: information that can be viewed by a user to whom the first security role has been assigned when the user to whom the first security role has been assigned interacts with a first software application, and one or more actions that can be performed by the user to whom the first security role has been assigned when the user to whom the first security role has been assigned interacts with the first software application.
The one or more first user interface elements of the foregoing system may allow the user to select the first security role from among a plurality of predefined security roles and/or select the one or more permissions associated with the first security role.
In one embodiment, the one or more first user interface elements further allow the user to access or create a second security role having at least one permission associated therewith that is not associated with the first security role. In further accordance with this embodiment, the second computer program logic may be programmed to cause the one or more processors to modify the one or more second user interface elements such that the one or more second user interface elements indicate: information that can be viewed by a user to whom the second security role has been assigned when the user to whom the second security role has been assigned interacts with the first software application, and one or more actions that can be performed by the user to whom the second security role has been assigned when the user to whom the second security role has been assigned interacts with the first software application.
In another embodiment, the computer program logic stored by the storage medium further includes third computer program logic. The third computer program logic is programmed to cause the one or more processors to determine whether the user has one or more required permissions. In further accordance with this embodiment, the first computer program logic may be programmed to cause the one or more processors to present the one or more first user interface elements and the second computer program logic may be programmed to cause the one or more processors to present the one or more second user interface elements only if a determination is made that the user has the one or more required permissions.
In a further embodiment, the first computer program logic and the second computer program logic comprise portions of a second software application that is different than the first software application, such as a tool within a toolkit associated with the first software application. In further accordance with such an embodiment, the computer program logic stored by the storage medium may further include third computer program logic. The third computer program logic may be programmed to cause the one or more processors to obtain configuration data stored in a database associated with the first software application. The configuration data may include at least one or more permissions that may be associated with a security role, and for each of the one or more permissions, one or more of information viewable by a user having the permission and one or more actions performable by a user having the permission. The first computer program logic may be programmed to cause the one or more processors to generate the one or more first user interface elements using the configuration data and the second computer program logic may be programmed to cause the one or more processors to generate the one or more second user interface elements using the configuration data. The third computer program logic may be further programmed to cause the one or more processors to cache the obtained configuration data.
Another computer-implemented method is described herein. In accordance with the method, one or more first user interface elements are presented that allow a first user to input an identifier of a second user of a first software application. Subsequent to the user inputting the identifier of the second user via the one or more first user interface elements, one or more security roles assigned to the second user are identified based on the identifier of the second user. One or more second user elements are then generated based at least on the identified one or more security roles. The one or more second user interface elements indicate of at least one of: information that can be viewed by the second user when the second user interacts with the first software application, and one or more actions that can be performed by the second user when the second user interacts with the first software application. The one or more second user interface elements are then presented. The foregoing method may further include presenting one or more third user interface elements that show the identified one or more security roles. The foregoing method may be performed by a second software application that is different than the first software application, such as a tool within a toolkit associated with the first application.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, it is noted that the claimed subject matter is not limited to the specific embodiments described in the Detailed Description and/or other sections of this document. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.
FIG. 1 is a block diagram of a role-based access control (RBAC) modeling and auditing system in accordance with an embodiment.
FIG. 2 depicts a flowchart of a method for performing security role modeling and auditing in accordance with an embodiment.
FIG. 3 depicts a flowchart of a method of presenting a simulated UI for a software application in accordance with an embodiment, wherein the simulated UI indicates information viewable and/or actions performable by a particular security role.
FIG. 4 depicts an example display area in which one or more first user interface elements used to access or create a security role and one or more second user interface elements used to represent a simulated UI for the security role are concurrently displayed in accordance with an embodiment.
FIG. 5 depicts a portion of a user interface of an RBAC modeling and auditing application in accordance with an embodiment that includes a plurality of first user interface elements that enable a user thereof to access or create a first security role.
FIG. 6 depicts another view of the portion of the user interface shown in FIG. 5.
FIG. 7 depicts a portion of a user interface of an RBAC modeling and auditing application in accordance with an embodiment that includes a plurality of second user interface elements that together comprise a simulated UI of a software application for a first security role.
FIG. 8 depicts a flowchart of an additional method of presenting a simulated UI for a software application in accordance with an embodiment, wherein the simulated UI indicates information viewable and/or actions performable by a particular security role.
FIG. 9 depicts another view of the portion of the user interface shown in FIG. 5 after a user has interacted therewith to create a second security role.
FIG. 10 depicts another view of the portion of the user interface shown in FIG. 7 after the second user interface elements thereof have been modified to comprise a simulated UI of a software application for a second security role.
FIG. 11 depicts a flowchart of a method for generating a simulated UI for an identified user of a software application in accordance with an embodiment.
FIG. 12 depicts a flowchart of a method of presenting a simulated UI for a software application in accordance with an embodiment, wherein the simulated UI indicates information viewable and/or actions performable by a particular user of the software application.
FIG. 13 shows a portion of a user interface of an RBAC modeling and auditing application in accordance with an embodiment that includes a plurality of first user interface elements that a user can interact with to input an identifier of a second user of a software application.
FIG. 14 depicts a portion of a user interface of an RBAC modeling and auditing application in accordance with an embodiment that includes a plurality of second user interface elements that together comprise a simulated UI of a software application for a particular user.
FIG. 15 depicts a portion of a user interface of an RBAC modeling and auditing application that displays the security roles associated with a particular user of a software application.
FIG. 16 is a block diagram of an example processor-based computer system that may be used to implement various embodiments.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
DETAILED DESCRIPTION
I. Introduction
The following detailed description refers to the accompanying drawings that illustrate exemplary embodiments of the present invention. However, the scope of the present invention is not limited to these embodiments, but is instead defined by the appended claims. Thus, embodiments beyond those shown in the accompanying drawings, such as modified versions of the illustrated embodiments, may nevertheless be encompassed by the present invention.
References in the specification to "one embodiment," "an embodiment," "an example embodiment," or the like, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of persons skilled in the relevant art(s) to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
A role-based access control (RBAC) modeling and auditing system will now be described. In particular, Section II describes an RBAC modeling and auditing system that enables a user to access and/or create security roles that can be applied to users of a first software application. When a security role having a particular set of permissions has been accessed or created, the RBAC modeling and auditing system can present a simulated user interface (UI) that indicates one or more of: information that can be viewed by a user to whom the security role has been assigned when interacting with the first software application and one or more actions that can be performed by the user to whom the security role has been assigned when interacting with the first software application. The RBAC modeling and auditing functionality may be embodied in a second software application, such as a tool, that is different from the first software application.
Section III describes "Run As" functionality of the RBAC modeling and auditing system. Such functionality enables a first user to identify a second user of the first software application. Then, based on one or more security roles that have been associated with the second user, the RBAC modeling and auditing system can present a simulated UI that indicates one or more of information that can be viewed by the second user when interacting with the first software application and one or more actions that can be performed by the second user when interacting with the first software application. Such "Run As" functionality may also be used to cause the RBAC modeling and auditing system to present the security role(s) associated with the second user.
Section IV describes an example processor-based computer system that may be used to implement certain features described herein, and Section V provides some concluding remarks.
II. Role-Based Access Control Modeling and Auditing System
FIG. 1 is a block diagram of a role-based access control (RBAC) modeling and auditing system 100 in accordance with an embodiment. As shown in FIG. 1, RBAC modeling and auditing system 100 includes an RBAC modeling and auditing application 110. RBAC modeling and auditing application 110 is intended to represent a computer program or process that is executed by a processor-based computer system or device to perform certain functions that will be described herein. One example of a processor-based computer system that may be used to execute RBAC modeling and auditing application 110will be described herein in reference to FIG. 16. However, that example and is not intended to be limiting. Depending upon the implementation, RBAC modeling and auditing application 110 may be executed by any of a desktop computer, a laptop computer, a tablet computer, a netbook computer, a handheld computing device, or the like.
RBAC modeling and auditing application 110 is programmed to perform certain functions in response to user input received from one or more user input devices 130. Such user input device(s) may be connected to or comprise an integrated part of a machine upon which RBAC modeling and auditing application 110 is running. User input device(s) 130 may include one or more of a keyboard, a mouse, a touch screen (e.g., a touch screen integrated with a display), a touch pad, a trackball, a joystick, a pointing stick, a wired glove, a motion tracking sensor, a video capture device such as a camera, or the like. However, these examples are not intended to be limiting and other user input device(s) not specifically mentioned herein may be used to provide user input to RBAC modeling and auditing application 110. In one embodiment, user input events generated when a user interacts with user input device(s) 130 are received by RBAC modeling and auditing application 110via an operating system (OS) that is executing on the same machine as RBAC modeling and auditing application 110.
RBAC modeling and auditing application 110 is also programmed to generate output in the form of graphical information for rendering to a display device 140. As will be discussed herein, such graphical information may represent one or more user interface elements associated with RBAC modeling and auditing application 110.
Display device 140 is intended to broadly represent any device that is capable of rendering graphical or video images for viewing by a user. In certain implementations, display device 140 may comprise a monitor, a projector, or other type of display device that is physically separate from a machine upon which RBAC modeling and auditing application 110 is running and connected thereto via a suitable wired and/or wireless connection. Alternatively, display device 140 may comprise a device that is integrated within a same physical structure or housing as a machine upon which RBAC modeling and auditing application 110 is running, such as an integrated display in a laptop computer, tablet computer, netbook computer, or the like. In certain embodiments, graphical information output by RBAC modeling and auditing application 110is provided to a graphics subsystem of a machine upon which RBAC modeling and auditing application 110 is running and the graphics subsystem causes such graphical information to be rendered to display device 140.
RBAC modeling and auditing application 110 is further programmed to obtain data from local storage 120 and to store data thereto. Local storage 120 is intended to represent any volatile or non-volatile, removable or non-removable computer storage medium or media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, software modules or other data. Local storage 120 may include, but is not limited to, one or more of RAM, ROM, EEPROM, flash memory or other memory technology, a hard disk, a CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired information and which can be accessed by RBAC modeling and auditing application 110.
As will be discussed herein, RBAC modeling and auditing application 110 is also programmed to access configuration data170 associated with a software application 150 that provides RBAC. Software application 150 is intended to represent a software application that allows users thereof to view information and perform actions by interacting with a corresponding UI thereof, where the information that can be viewed and the actions that can be performed by each user depend upon one or more security role(s) that are currently assigned to that user in accordance with an RBAC scheme.
In one embodiment, software application 150 comprises SYSTEM CENTER 2012 CONFIGURATION MANAGER, published by Microsoft Corporation of Redmond Wash. SYSTEM CENTER 2012 CONFIGURATION MANAGER is a systems management software product that enables users thereof to manage large groups of computer systems and that provides features such as remote control, patch management, software distribution, operating system deployment, network access protection, and hardware and software inventory. SYSTEM CENTER 2012 CONFIGURATION MANAGER also supports an RBAC scheme. In particular, SYSTEM CENTER 2012 CONFIGURATION MANAGER permits an administrator to access and create various security roles having different sets of permissions and to assign one or more of these security roles to a user. When such user logs into SYSTEM CENTER 2012 CONFIGURATION MANAGER, he is presented with a UI (in particular, an administration console UI) that enables him to view only that information and perform only those actions that are authorized for his assigned security role(s).
However, this is only one example, and software application 150 may comprise any other software application that determines the information that can be viewed and/or the actions that can be performed by a user via a UI based on one or more security roles assigned thereto.
Configuration data 170 comprises data associated with software application 150. Configuration data 170 may be stored in a non-volatile storage system or device that is accessible to software application 150. Configuration data 170 may be stored within a database, a file, or some other collection of data. In an embodiment, configuration data 170 includes one or more of: (1) one or more security roles that may be assigned to users of software application 150 and one or more permissions associated with each security role, (2) one or more permissions that may be associated with a security role and for each of the one or more permissions, one or more of information viewable by a user having the permission and one or more actions performable by a user having the permission, and (3) one or more users of software application 150 and for each user, one or more security roles that have been assigned to the user. Configuration data 170 may include other information associated with software application 150 as well.
RBAC modeling and auditing application 110 is further configured to access a credential system 160. Credential system 160is a system that operates to store and retrieve credentials, such as a username and password, associated with users of a computer system or application. In one embodiment, credential system 160 stores credentials for users of software application 150. In one embodiment, credential system 160 is implemented using ACTIVE DIRECTORY®, a directory service published by Microsoft Corporation. However, this example is not intended to be limiting and any of a wide variety of credential systems may be used.
In one embodiment, software application 150 and credential system 160 are executed by machines that are remotely located from a machine on which RBAC modeling and auditing application 110 is executed. In accordance with such an embodiment, such machines may be connected to each other via one or more wired and/or wireless networks (including local area and wide area networks) and communications between the machines may be carried out using well-known network communication protocols. In further accordance with such an embodiment, configuration data 170 may be stored remotely with respect to a machine on which RBAC modeling and auditing application 110 is executed and may be accessed by RBAC modeling and auditing application 110 via one or more wired and/or wireless network(s).
In an alternate embodiment, RBAC modeling and auditing application 110 is executed on the same machine as one or more of software application 150 and credential system 160. Still other configurations are possible.
In one embodiment, RBAC modeling and auditing application 110 comprises a tool within a toolkit associated with software application 150 that can be executed independently of software application 150 to perform RBAC modeling and auditing functions therefor. The tool may be lightweight in the sense that it does not require significant computing resources for execution, and its execution may require less computing resources as compared to those required to interact with software application 150.
For example, in an embodiment in which software application 150 comprises SYSTEM CENTER 2012 CONFIGURATION MANAGER, RBAC modeling and auditing application 110 may comprise a tool within SYSTEM CENTER 2012 CONFIGURATION MANAGER TOOLKIT, published by Microsoft Corporation of Redmond, Wash. Such tool comprises a lightweight component that may be executed independently of SYSTEM CENTER 2012 CONFIGURATION MANAGER to perform RBAC modeling and auditing functions.
In an alternate implementation (not shown in FIG. 1), the functionality of RBAC modeling and auditing application 110 may actually be included within software application 150.
As further shown in FIG. 1, RBAC modeling and auditing application 110 includes computer program logic. In particular, RBAC modeling and auditing application 110 includes security role modeling and auditing logic 112 and "run as" logic 114. The functions of security role modeling and auditing logic 112 will now be described, and the functions of "run as" logic 114will be described in the next section.
Generally speaking, security role modeling and auditing logic 112 enables a user to access and/or create security roles that can be applied to users of software application 150. When a security role having a particular set of permissions has been accessed or created, security role modeling and auditing logic 112 can present a simulated UI that indicates one or more of: information that can be viewed by a user to whom the security role has been assigned when interacting with software application 150 and one or more actions that can be performed by the user to whom the security role has been assigned when interacting with software application 150.
The manner of operation of security role modeling and auditing logic 112 will now be described with further reference to flowchart 200 of FIG. 2. The steps of flowchart 200 may comprise operations performed by security role modeling and auditing logic 112 when such logic executed by one or more processors. Although the method of flowchart 200 is described herein in reference to certain components of RBAC modeling and auditing system 100, it is noted that the method is not so limited, and the method may be performed by other components or systems.
As shown in FIG. 2, the method of flowchart 200 begins at step 202. After step 202, control passes to decision step 204. During decision step 204, security role modeling and auditing logic 112 determines whether or not a user of RBAC modeling and auditing application 110 has one or more permissions necessary to utilize the functions thereof. This step may include, for example, determining whether the user of RBAC modeling and auditing application 110 has been assigned one or more security roles (e.g., full administrator, read-only analyst, or security administrator), has been assigned one or more security scopes (wherein a security scope indicates access to specific secured objects), and/or has been assigned one or more collections (wherein a collection is a group of devices or users the user can manage). However, these are only examples, and a variety of methods may be used to determine if the user of RBAC modeling and auditing application 110 has the necessary permission(s).
If security role modeling and auditing logic 112 determines during decision step 204 that the user of RBAC modeling and auditing application 110 does not have the permission(s) necessary to utilize the functions thereof, then the method ends at step 214.
However, if security role modeling and auditing logic 112 determines during decision step 204 that the user of RBAC modeling and auditing application 110 does have the permission(s) necessary to utilize the functions thereof, then control passes to step 206.
During step 206, security role modeling and auditing logic 112 obtains configuration data 170 associated with software application 150. In this particular embodiment, configuration data 170 is stored in a storage system that is remote with respect to the machine upon which RBAC modeling and auditing application 110 is running and is accessible thereto via one or more networks. Thus, step 206 comprises obtaining configuration data 170 via the one or more networks. After step 206, control passes to step 208.
During step 208, security role modeling and auditing logic 112 caches the configuration data 170 obtained during step 206in local storage 120, where it is represented as cached configuration data 122. By caching such configuration data locally, performance of certain features of RBAC modeling and auditing application 110 may be improved. After step 208, control passes to decision step 210.
During decision step 210, security role modeling and auditing logic 112 determines whether the user of RBAC modeling and auditing application 110 has activated a modeling function for a security role that he or she has accessed or created using the application. Various exemplary methods for accessing/creating a security role and activating the modeling function using RBAC modeling and auditing application 110 will be provided herein.
If security role modeling and auditing logic 112 determines during decision step 210 that the user of RBAC modeling and auditing application 110 has not activated a modeling function for a security role that he or she has accessed or created using the application, then the method ends at step 214.
However, if security role modeling and auditing logic 112 determines during decision step 210 that the user of RBAC modeling and auditing application 110 has activated a modeling function for a security role that he or she has accessed or created using the application, then control passes to step 212.
During step 212, security role modeling and auditing logic 112 generates and presents a simulated UI of software application150 to the user of RBAC modeling and auditing application 110. Security role modeling and auditing logic 112 generates the simulated UI by analyzing the accessed/created security role and cached configuration data 122. The simulated UI may represent the UI that would be presented to a user to whom the accessed/created security role has been assigned when such user interacts with (e.g., logs into) software application 150. In particular, the simulated UI may indicate one or more of information that could be viewed by a user to whom the accessed/created security role has been assigned when interacting with software application 150 and one or more actions that can be performed by the user to whom the accessed/created security role has been assigned when interacting with software application 150. After step 212, the method ends at step 214.
The manner of operation of security role modeling and auditing logic 112 will now be further illustrated with respect to FIG. 3. In particular, FIG. 3 depicts a flowchart 300 of a method of presenting a simulated UI for a software application, wherein the simulated UI indicates information viewable and/or actions performable by a particular security role. The steps of flowchart300 may comprise operations performed by security role modeling and auditing logic 112 when such logic is executed by one or more processors. Although the method of flowchart 300 is described herein in reference to certain components of RBAC modeling and auditing system 100, it is noted that the method is not so limited, and the method may be performed by other components or systems.
As shown in FIG. 3, the method of flowchart 300 begins at step 302, in which security role modeling and auditing logic 112presents one or more first user interface elements that allow a user of RBAC modeling and auditing application 110 to access or create security roles. The functions of step 302 may be performed, for example, by first computer program logic within security role modeling and auditing logic 112.
At step 304, the user of RBAC modeling and auditing application 110 utilizes the first user interface element(s) to access or create the first security role.
At step 306, security role modeling and auditing logic 112 presents one or more second user interface elements that indicate information that can be viewed by a user to whom the first security role has been assigned when interacting with software application 150 and/or one or more actions that can be performed by the user to whom the first security role has been assigned when interacting with software application 150. These second user interface element(s) comprise a simulated UI of software application 150. The functions of step 306 may be performed, for example, by second computer program logic within security role modeling and auditing logic 112.
In an embodiment, the method of flowchart 300 further includes obtaining configuration data 170 stored in a database associated with software application 150. The function of obtaining configuration data 170 may be performed, for example, by third computer program logic within security role modeling and auditing logic 112. In certain implementations, the third computer program logic may be programmed to cache configuration data 170 in local storage 120, where it is represented as cached configuration data 122. Such configuration data may be used to generate at least one of the one or more first user interface elements and the one or more second user interface elements.
In one embodiment, security role modeling and auditing logic 112 is configured to present the first user interface element(s) discussed above in reference to steps 302 and 304 and the second user interface element(s) discussed above in reference to step 306 in a concurrent manner. This is illustrated in FIG. 4, which shows an example display area 410 of display device140. Display area 410 may comprise, for example and without limitation, an entirety of a screen of display device 140 or a windowed area within a screen of display device 140. As shown in FIG. 4, first user interface element(s) 420, which may represent the first user interface element(s) discussed above in reference to steps 302 and 304, and second user interface element(s) 430, which may represent the second user interface element(s) discussed above in reference to step 306, are concurrently displayed within display area 410. Such an implementation advantageously allows a user of RBAC modeling and auditing application 110 to immediately perceive how changes to a security role created or accessed using first user interface element(s) will impact a simulated UI of software application 150 represented by second user interface element(s)430.
Certain examples of the first user interface element(s) that a user can interact with to access or create a first security role as referred to in steps 302 and 304 of flowchart 300 will now be provided. By way of example, FIG. 5 shows a portion 500 of a user interface of RBAC modeling and auditing application 110 that includes a plurality of first user interface elements that a user can interact with to access or create a security role.
In particular, as shown in FIG. 5, user interface portion 500 includes a drop-down menu 502 that includes a plurality of built-in or predefined security roles and a checkbox associated with each. By interacting with the checkbox associated with a particular built-in security role (e.g., by clicking on the checkbox using a pointing device such as a mouse or in some other manner), a user of RBAC modeling and auditing application 110 can access the particular built-in security role. In the example shown in FIG. 5, the user of RBAC modeling and auditing application 110 has selected the built-in security role "Endpoint Protection Manager" by interacting with the checkbox associated with it.
Once a user of RBAC modeling and auditing application 110 has selected a built-in security role, the security role is accessed and various permissions associated therewith are displayed in a permissions menu 504. FIG. 6 provides another view of user interface portion 500 in which permissions menu 504 is unobstructed by drop-down menu 502. As shown inFIGS. 5 and 6, permissions menu 504 includes a plurality of security objects and an expander and checkbox associated with each. For example, the security object "Software Titles" has an expander 510 and a checkbox 512 associated therewith.
Each security object shown in permissions menu 504 has one or more operations associated therewith (e.g., read, modify, delete, or the like). The operations associated with a security object may vary from security object to security object. In permissions menu 504, the state of the checkbox associated with a security object indicates what permissions the current security role has with respect to the security object. For example, if the checkbox is unchecked, the current security role has no permissions with respect to the corresponding security object. If the checkbox is checked, the current security role can perform all the operations that are associated with the corresponding secured object. If the checkbox is checked with a lightly-shaded or "grayed out" check, the current security role can only perform some of the operations that are associated with the corresponding security object.
As shown in FIGS. 5 and 6, the permissions associated with the security role "Endpoint Protection Manager" enable all operations to be performed with respect to the security objects "Alert Subscription," "Alerts," "Antimalware Policy," "Configuration Policy," and "Firewall Settings." Such permissions also enable some operations (but not all operations) to be performed with respect to the security objects "Collection" and "Site." Such permissions do not enable any operations to be performed with respect to any of the other security objects shown in permissions menu 504.
To access the operations associated with a particular security object, a user of RBAC modeling and auditing application 110can interact with the expander associated with the particular security object in permissions menu 504 (e.g., by clicking on the expander using a pointing device such as a mouse or in some other manner). In response to such interaction, the operations associated with the particular security object will be displayed in permissions menu 504 along with a checkbox for each. Such checkboxes can be interacted with to assign or remove permissions at an operation level rather than at a security object level.
A user of RBAC modeling and auditing application 110 can thus interact with the user interface elements of user interface portion 500 to access a predefined or built-in security role and view the permissions associated with that security role. By varying the permissions through interaction with permissions menu 504, such user can also create entirely new security roles. An "export" button 508 may be interacted with to export digital representations of new security roles for subsequent importing into software application 150.
As further shown in FIG. 5, user interface portion 500 also includes an "analyze" button 506. By interacting with "analyze" button 506 (e.g., by clicking on "analyze" button 506 using a pointing device such as a mouse or in some other manner), a user of RBAC modeling and auditing application 110 can cause a simulated UI associated with the current security role to be presented. As previously discussed, such simulated UI may comprise one or more second user interface elements that indicate information that can be viewed by a user to whom the first security role has been assigned when interacting with software application 150 and/or one or more actions that can be performed by the user to whom the first security role has been assigned when interacting with software application 150.
By way of example, FIG. 7 shows a portion 700 of a user interface of RBAC modeling and auditing application 110 that includes a plurality of second user interface elements that together comprise a simulated UI of a software application, such as software application 150, for a particular security role. In particular, user interface portion 700 represents the simulated UI for the "Endpoint Protection Manager" security role that was accessed using user interface portion 500 as previously described.
As shown in FIG. 7, user interface portion 700 includes elements that indicate various types of information that can be viewed by a user to whom the "Endpoint Protection Manager" security role has been assigned when such user interacts with software application 150. For example, the presence of an "assets and compliance" button 702 indicates that a user to whom the "Endpoint Protection Manager" security role has been assigned can obtain information about information technology (IT) assets that can be managed within an enterprise and information concerning compliance rules that may be enforced with respect to such assets. As another example, the presence of a "monitoring" button 704 indicates that a user to whom the "Endpoint Protection Manager" security role has been assigned can obtain information about monitoring functionality associated with such assets, including alerts, reporting, and the like.
As also shown in FIG. 7, user interface portion 700 also includes elements that indicate actions that may be performed by a user to whom the "Endpoint Protection Manager" security role has been assigned when such user interacts with software application 150. For example, an actions menu 706 and a query actions menu 708 indicate actions that may be performed with respect to certain device collections identified in user interface portion 700.
The manner of operation of security role modeling and auditing logic 112 will now be further illustrated with respect to FIG. 8. In particular, FIG. 8 depicts a flowchart 800 of an additional method of presenting a simulated UI for a software application, wherein the simulated UI indicates information viewable and/or actions performable by a particular security role. The steps of flowchart 800 may comprise operations performed by security role modeling and auditing logic 112 when such logic is executed by one or more processors. Although the method of flowchart 800 is described herein in reference to certain components of RBAC modeling and auditing system 100, it is noted that the method is not so limited, and the method may be performed by other components or systems.
As shown in FIG. 8, the method of flowchart 800 begins at step 802, in which a user of RBAC modeling and auditing application 110 utilizes the first user interface element(s) described above in reference to flowchart 300 of FIG. 3 to access or create a second security role. The second security role has at least one permission associated therewith that is not associated with the first security role discussed above in reference to flowchart 300 of FIG. 3. As discussed above in reference to step 302 of flowchart 300, the presentation of the first user interface element(s) may be performed by first computer program logic within security role modeling and auditing logic 112.
At step 804, security role modeling and auditing logic 112 modifies the one or more second user interface element(s) described above in reference to flowchart 300 of FIG. 3 such that the second user interface element(s) indicate information that can be viewed by a user to whom the second security role has been assigned when interacting with software application150 and/or one or more actions that can be performed by the user to whom the second security role has been assigned when interacting with software application 150. The functions of step 804 may be performed, for example, by the second computer program logic within security role modeling and auditing logic 112 discussed above in reference to step 306 of flowchart 300.
One example of the manner in which step 802 may be performed will now be described in reference to FIG. 9. FIG. 9depicts another view of user interface portion 500 after a user of RBAC modeling and auditing application 110 has interacted therewith to create a second security role. In particular, as shown in FIG. 9, the user has modified the permissions associated with the security role "Endpoint Protection Manager" by checking the checkbox associated with the security object "Applications," thereby granting the security role permission to perform all the operations associated with security object "Applications." This has the effect of creating a new, custom security role that can then be analyzed and exported.
One example of the manner in which step 804 may be performed will now be described in reference to FIG. 10. FIG. 10depicts another view of user interface portion 700 after the user of RBAC modeling and auditing application 110 has created the new, custom security role in the manner discussed above in reference to FIG. 9 and has activated "analyze" button 506. In response to the activation of "analyze" button 506, the second user interface element(s) that together comprise the simulated UI are modified as shown in FIG. 10 to indicate the information viewable and actions performable by a user to whom the new, custom security role has been assigned.
Thus, as shown in FIG. 10, user interface portion 700 has been modified to include new elements that indicate new types of information that can be viewed by a user to whom the custom security role has been assigned when such user interacts with software application 150. For example, the presence of a new "software library" button 1002 indicates that a user to whom the custom security role has been assigned can obtain information about software assets that can be managed within an enterprise, such as applications that can be installed on machines, software updates that can be performed, or the like. Such information would not be available to a user to whom the "Endpoint Protection Manager" role has been assigned, and thus the simulated UI has been automatically changed to reflect that.
As also shown in FIG. 10, user interface portion 700 also includes new elements that indicate new actions that may be performed by a user to whom the custom security role has been assigned when such user interacts with software application 150. Such new actions are identified, for example, in actions menu 706 and query actions menu 708.
Thus, by automatically generating and presenting a simulated UI in the manner described above, security role modeling and auditing logic 112 makes it easy for a user of RBAC modeling and auditing application 110 to determine what information and actions will be made accessible via the UI of software application 150 for a security role accessed or created using RBAC modeling and auditing application 110.
III. "Run As" Functionality
Referring again to FIG. 1, it can be seen that RBAC modeling and auditing application 110 includes "run as" logic 114. Generally speaking, "run as" logic 114 enables a user of RBAC modeling and auditing application 110 to identify a user of software application 150. Then, based on one or more security roles that have been associated with the user of software application 150, "run as" logic 114 presents a simulated UI that indicates one or more of information that can be viewed by the user of software application 150 when interacting with software application 150 and one or more actions that can be performed by the user of software application 150 when interacting with software application 150. "Run as" logic 114 may also be used to present the security role(s) associated with the user of software application 150.
The manner of operation of "run as" logic 114 will now be described with further reference to flowchart 1100 of FIG. 11. The steps of flowchart 1100 may comprise operations performed by "run as" logic 114 when such logic executed by one or more processors. Although the method of flowchart 1100 is described herein in reference to certain components of RBAC modeling and auditing system 100, it is noted that the method is not so limited, and the method may be performed by other components or systems.
As shown in FIG. 11, the method of flowchart 1100 begins at step 1102. After step 1102, control passes to decision step1104. During decision step 1104, "run as" logic 114 determines whether or not a user of RBAC modeling and auditing application 110 has one or more permissions necessary to utilize the functions thereof. This step may include, for example, determining whether the user of RBAC modeling and auditing application 110 has been assigned one or more security roles (e.g., full administrator, read-only analyst, or security administrator), has been assigned one or more security scopes (wherein a security scope indicates access to specific secured objects), and/or has been assigned one or more collections (wherein a collection is a group of devices or users the user can manage). However, these are only examples, and a variety of methods may be used to determine if the user of RBAC modeling and auditing application 110 has the necessary permission(s).
If "run as" logic 114 determines during decision step 1104 that the user of RBAC modeling and auditing application 110does not have the permission(s) necessary to utilize the functions thereof, then the method ends at step 1116.
However, if "run as" logic 114 determines during decision step 1104 that the user of RBAC modeling and auditing application 110 does have the permission(s) necessary to utilize the functions thereof, then control passes to step 1106.
During step 1106, "run as" logic 114 obtains configuration data 170 associated with software application 150. In this particular embodiment, configuration data 170 is stored in a storage system that is remote with respect to the machine upon which RBAC modeling and auditing application 110 is running and is accessible thereto via one or more networks. Thus, step 1106 comprises obtaining configuration data 170 via the one or more networks. After step 1106, control passes to step1108.
During step 1108, "run as" logic caches the configuration data 170 obtained during step 1106 in local storage 120, where it is represented as cached configuration data 122. By caching such configuration data locally, performance of certain features of RBAC modeling and auditing application 110 may be improved. After step 1108, control passes to decision step1110.
During decision step 1110, "run as" logic 114 determines whether the user of RBAC modeling and auditing application 110has activated a "run as" function for an identified user of software application 150. Various exemplary methods for activating a "run as" function for an identified user of software application 150 will be described herein.
If "run as" logic 114 determines during decision step 1110 that the user of RBAC modeling and auditing application 110 has not activated a "run as" function for an identified user of software application 150, then the method ends at step 1116.
However, if "run as" logic 114 determines during decision step 1110 that the user of RBAC modeling and auditing application 110 has activated a "run as" function for an identified user of software application 150, then control passes to step 1112.
During step 1112, "run as" logic 114 obtains audited user information from credential system 160 for the identified user of software application 150. This step may be performed, for example, to ensure that the identified user of software application150 is a valid user. After step 1112, control passes to step 1114.
During step 1114, "run as" logic 114 generates and presents a simulated UI of software application 150 to the user of RBAC modeling and auditing application 110. "Run as" logic 112 generates the simulated UI by analyzing the credentials of the identified user and cached configuration data 122. The simulated UI may represent the UI that would be presented to the identified user of software application 150 when such identified user interacts with (e.g., logs into) software application 150. In particular, the simulated UI may indicate one or more of information that could be viewed by the identified user when interacting with software application 150 and one or more actions that can be performed by the identified user when interacting with software application 150. After step 1114, the method ends at step 1116.
The manner of operation of "run as" logic 114 will now be further illustrated with respect to FIG. 12. In particular, FIG. 12depicts a flowchart 1200 of a method of presenting a simulated UI for a software application, wherein the simulated UI indicates information viewable and/or actions performable by a particular user of the software application. The steps of flowchart 1200 may comprise operations performed by "run as" logic 114 when such logic is executed by one or more processors. Although the method of flowchart 1200 is described herein in reference to certain components of RBAC modeling and auditing system 100, it is noted that the method is not so limited, and the method may be performed by other components or systems.
As shown in FIG. 12, the method of flowchart 1200 begins at step 1202, in which "run as" logic 114 presents one or more first user interface elements that allow a user of RBAC modeling and auditing application 110 (a "first user") to input an identifier of a user of a software application, such as software application 150 (a "second user"). The identifier may comprise, for example, a domain and username combination. However, this example is not intended to be limiting and a wide variety of other user identifiers may be used, including but not limited to an e-mail address or the like.
At step 1204, the first user utilizes the first user interface component(s) to input the identifier of the second user of software application 150.
At step 1206, "run as" logic 114 identifies one or more security roles assigned to the second user based on the identifier of the second user.
At step 1208, "run as" logic 114 generates one or more second user interface elements based on at least the identified one or more security roles assigned to the second user. The second user interface element(s) indicate information that can be viewed by the second user when interacting with software application 150 and/or one or more actions that can be performed by the second user when interacting with software application 150. These second user interface element(s) comprise a simulated UI of software application 150.
At step 1210, "run as" logic 114 presents the second user interface element(s) to the first user.
In an embodiment, the method of flowchart 1200 further includes obtaining configuration data 170 stored in a database associated with software application 150. In certain implementations, the configuration data 170 is cached in local storage120, where it is represented as cached configuration data 122. Such configuration data may be used to generate at least one of the one or more second user interface elements discussed above.
Certain examples of the first user interface element(s) that a user can interact with to input an identifier of a second user of software application 150 as referred to in steps 1202 and 1204 of flowchart 1200 will now be provided. By way of example,FIG. 13 shows a portion 1300 of a user interface of RBAC modeling and auditing application 110 that includes a plurality of first user interface elements that a user can interact with to input an identifier of a second user of software application 150.
In particular, as shown in FIG. 13, user interface portion 1300 includes a "run as" button 1302, a text entry box 1304 and a "check" button 1306. A user of RBAC modeling and auditing application 110 may access the various "run as" features described herein by first interacting with "run as" button 1302. For example, in one embodiment, when a user activates "run as" button 1302, text entry box 1304 and "check" button 1306 appear. A user of RBAC modeling and auditing application110 may then enter an identifier of the second user of software application 150 in text entry box 1304. In the example shown in FIG. 13, a user of RBAC modeling and auditing application 110 has input an identifier of the second user in the form of the domain\name combination "cmv413128dom\kevin". After typing in the identifier, the user of RBAC modeling and auditing application 110 may then interact with "check" button 1306 to cause a simulated UI for the second user to appear.
FIG. 14 shows the simulated UI for the second user. In particular, FIG. 14 shows a portion 1400 of a user interface of RBAC modeling and auditing application 110 that includes a plurality of second user interface elements that together comprise a simulated UI of software application 150 for the second user (i.e., the user identified by the domain/name "cmv413128dom\kevin").
As shown in FIG. 14, user interface portion 1400 includes elements that indicate various types of information that can be viewed by the second user when the second user interacts with software application 150. For example, the presence of an "assets and compliance" button 1402 indicates that the second user can obtain information about IT assets that can be managed within an enterprise and information concerning compliance rules that may be enforced with respect to such assets. As another example, the presence of a "monitoring" button 1404 indicates that the second user can obtain information about monitoring functionality associated with such assets, including alerts, reporting, and the like. As a still further example, the presence of an "administration" button 1406 indicates that the second user can obtain information relating to administration of the IT assets and various users thereof.
As also shown in FIG. 14, user interface portion 1400 also includes elements that indicate actions that may be performed by the second user when such user interacts with software application 150. For example, an actions menu 1406 and a query actions menu 1408 indicate actions that may be performed with respect to certain administrative users identified in user interface portion 1400.
In accordance with further embodiment, "run as" logic 114 may also be configured to present one or more third user interface elements that show the security roles associated with the second user. An example of this is shown in FIG. 15. In particular, FIG. 15 shows a portion 1500 of a user interface of RBAC modeling and auditing application 110 that shows the security roles associated with the second user. In particular, portion 15 shows that the user identified by the domain/name "cmv413128dom\kevin" belongs to the security group "Security Admins" and has been assigned the security role "Security Administrator."
IV. Example Processor-Based System Implementation
FIG. 16 depicts an example processor-based computer system 1600 that may be used to implement various embodiments described herein. For example, system 1600 may be used to execute RBAC modeling and auditing application 110, software application 150, and/or credential system 160 as described above in reference to FIG. 1 as well as any components included therein. The description of system 1600 provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).
As shown in FIG. 16, system 1600 includes a processing unit 1602, a system memory 1604, and a bus 1606 that couples various system components including system memory 1604 to processing unit 1602. Processing unit 1602 may comprise one or more processors or processing cores. Bus 1606 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory 1604 includes read only memory (ROM) 1608 and random access memory (RAM) 1610. A basic input/output system 1612 (BIOS) is stored in ROM 1608.
System 1600 also has one or more of the following drives: a hard disk drive 1614 for reading from and writing to a hard disk, a magnetic disk drive 1616 for reading from or writing to a removable magnetic disk 1618, and an optical disk drive 1620 for reading from or writing to a removable optical disk 1622 such as a CD ROM, DVD ROM, BLU-RAY™ disk or other optical media. Hard disk drive 1614, magnetic disk drive 1616, and optical disk drive 1620 are connected to bus 1606 by a hard disk drive interface 1624, a magnetic disk drive interface 1626, and an optical drive interface 1628, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of computer-readable media can be used to store data, such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like.
A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These program modules include an operating system 1630, one or more application programs 1632, other program modules 1634, and program data 1636. In accordance with various embodiments, the program modules may include computer program logic that is executable by processing unit 1602 to perform any or all of the functions and features of any of RBAC modeling and auditing application 110, software application 150, and/or credential system 160 as described above in reference to FIG. 1as well as any components included therein. The program modules may also include computer program logic that, when executed by processing unit 1602, performs any of the steps or operations shown or described in reference to the flowcharts of FIGS. 2, 3, 8, 11 and 12.
A user may enter commands and information into system 1600 through input devices such as a keyboard 1638 and a pointing device 1640. Other input devices (not shown) may include a microphone, joystick, game controller, scanner, or the like. In one embodiment, a touch screen is provided in conjunction with a display 1644 to allow a user to provide user input via the application of a touch (as by a finger or stylus for example) to one or more points on the touch screen. These and other input devices are often connected to processing unit 1602 through a serial port interface 1642 that is coupled to bus1606, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).
A display 1644 is also connected to bus 1606 via an interface, such as a video adapter 1646. In addition to display 1644, system 1600 may include other peripheral output devices (not shown) such as speakers and printers.
System 1600 is connected to a network 1648 (e.g., a local area network or wide area network such as the Internet) through a network interface or adapter 1650, a modem 1652, or other suitable means for establishing communications over the network. Modem 1652, which may be internal or external, is connected to bus 1606 via serial port interface 1642.
As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium" are used to generally refer to media such as the hard disk associated with hard disk drive 1614, removable magnetic disk 1618, removable optical disk 1622, as well as other media such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like. Such computer-readable storage media are distinguished from and non-overlapping with communication media (do not include communication media). Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media. Embodiments are also directed to such communication media.
As noted above, computer programs and modules (including application programs 1632 and other program modules 1634) may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such computer programs may also be received via network interface 1650, serial port interface 1642, or any other interface type. Such computer programs, when executed or loaded by an application, enable computer 1600 to implement features of embodiments of the present invention discussed herein. Accordingly, such computer programs represent controllers of the computer 1600.
Embodiments are also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a data processing device(s) to operate as described herein. Embodiments of the present invention employ any computer-useable or computer-readable medium, known now or in the future. Examples of computer-readable mediums include, but are not limited to storage devices such as RAM, hard drives, floppy disks, CD ROMs, DVD ROMs, zip disks, tapes, magnetic storage devices, optical storage devices, MEMs, nanotechnology-based storage devices, and the like.
In alternative implementations, any of RBAC modeling and auditing application 110, software application 150, and/or credential system 160 as described above in reference to FIG. 1 as well as any components included therein may be implemented as hardware logic/electrical circuitry or firmware. In accordance with further embodiments, one or more of these components may be implemented in a system-on-chip (SoC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.
V. Conclusion
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and details can be made therein without departing from the spirit and scope of the invention. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.