Role navigation designer and verifier

Systems and methods are provide for providing role navigation design and verification. An embodiment includes displaying user interface having at least one secured element, identifying a first privilege needed for access the secured element, and associating the privilege with a role, whereby a user having the role may access the at least one secured element.

FIELD OF THE INVENTION

One embodiment is directed generally to computer access, and more particularly to role and privilege managed computer access.

BACKGROUND INFORMATION

In a typical role-based access control (“RBAC”) systems, access to an object within a computer system is provided to the members of groups termed “roles”; all subjects belonging to a given role have the same privileges to access various objects within the system. Individuals are then granted access to objects by being assigned membership in appropriate roles. RBAC is considered useful in many commercial environments because it allows access to the computer system to be conveniently organized along lines corresponding to the actual duties and responsibilities of individuals within organizations. For example, RBAC allows the access provided by roles to conform to a preexisting hierarchy; in a hospital environment, members of the “doctor” role will have broader access to protected objects than would members of “nurse”, who will in turn be given broader access than “health-care provider”. Various types of privilege can be conveniently organized as a function of role assignments. For example, “doctor” membership may allow the user the privilege to read from or write to a pharmacy record, while “pharmacist” may only allow the privilege of reading the record.

An advantage of RBAC is that it allows the access privileges provided to individuals to be very conveniently reconfigured as the individuals change job requirements, simply by deleting one's original assignment to a first role and adding one to the new role.

SUMMARY OF THE INVENTION

One embodiment is a method for providing role navigation design and verification. An embodiment includes displaying user interface having at least one secured element, identifying a first privilege needed for access the secured element, and associating the privilege with a role, whereby a user having the role may access the at least one secured element.

DETAILED DESCRIPTION

An embodiment is directed to a RBAC system manager that provides role design and verification for enterprise software applications based on navigation of a user interface. Permissions or privileges, i.e., the access rights to perform an action such as read, write, delete or execute, are granted to roles by selecting higher level navigation elements. For example, a system administrator might grant a role permission to view a particular intranet page by navigating to the page, selecting a role, and granting permission to view that page to the role.

FIG. 1is a block diagram of a system10that can implement this embodiment. System10includes a bus12or other communication mechanism for communicating information, and a processor22coupled to bus12for processing information. Processor22may be any type of general or specific purpose processor. System10further includes a memory14for storing information and instructions to be executed by processor22. Memory14can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System10further includes a communication device20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system10directly, or remotely through a network or any other method.

Processor22is further coupled via bus12to a display24, such as a Liquid Crystal Display (“LCD”), for displaying information to a user. A keyboard26and a cursor control device28, such as a computer mouse, is further coupled to bus12to enable a user to interface with system10.

In one embodiment, memory14stores software modules that provide functionality when executed by processor22. The modules include an operating system15that provides operating system functionality for system10. The modules further include a role navigation designer module114and a role navigation verifier module116. These modules are described in greater detail below. Additional, fewer, and/or different modules18may also be included in system10. In one embodiment role navigation designer module114and role navigation verifier module116are part of the “Oracle E-Business Suite Release 12” enterprise application system from Oracle Corp.

With reference now toFIG. 2, a block diagram depicts a typical role-based access control system. The elements shown within security management system200merely represent some of the general concepts, objects, relationships, or associations within a role-based access control system. Depending on the implementation of the security management system, the objects and relationships may have different names and functions.

Within an enterprise, an employee may “belong” to one or more organizational units, such as a department and a project. User object202, which represents an employee, is associated with organizational object204. Organizational objects204-208represent multiple organizational units within an enterprise, and each organizational unit is assumed to have multiple employees or users, and information about those employees are stored within corporate directory210, which may be implemented as a data directory supported by one or more directory services.

User object202represents not only an employee but also a manager, so user object202is associated with group object212, which represents a group of similar managers. InFIG. 2, organizational unit objects206and208are shown as being associated with group object212. It may be assumed that each organizational unit within the enterprise has a manager of the type represented by group object212, although the specific employees within the organizations represented by objects206and208are not specifically identified in the diagram.

Depending on an employee's title or job description within the enterprise, an employee may be assigned one or more roles within the security management/administration system. Group object212is associated with role object214, which defines a role having basic access rights to resources216and218. For example, each employee of the enterprise may have access to certain types of basic computational resources, such as an intranet account for accessing an internal, enterprise-wide, Web site. This basic access is also applicable to each manager associated with group object212, so group object212has been associated with role object214; resource216might represent authorization to access a particular internal Web server, while resource218might represent authorization to access a firewall to the Internet.

However, each manager within the organization might require special privileges for accessing a invoice management application. In order to reflect actual business processes, role object220is defined and associated with group object212, and role object220has a set of access rights222that determine exactly how any user associated with role object220can use resource224, which might represent the invoice management application. The invoice management application may be used by different types of employees within the enterprise who have different authorized uses of the invoice management application. For example, a clerical employee may be allowed to view a purchase order in the invoice management application, but not to approve it, whereas a manager role would have permission to approve the purchase order.

As shown with respect to the description ofFIG. 2above, a security administrator may be burdened with manually (through an appropriate management application) relating resources to roles within a prior art security administration system. Furthermore, an error condition exists where a role has inconsistent privileges. For example, a user may be privileged to approve a purchase order but have no means to review the purchase order that they will approve. The task to approve a purchase order may be implemented as a button on the view purchase order page and a user may have privileges to approve a purchase order but not to view a purchase order. This condition exists because the assignment of privileges to roles is not done in the context of the navigation paths and user interfaces that allow the performance of tasks requiring those privileges.

An embodiment of role navigation designer114avoids this error condition by providing a user interface navigation-based model of role and privilege assignment.FIG. 3illustrates an example user interface301where a system administrator may utilize role navigation designer114to grant permissions and privileges to roles. User interface301is, by way of example and not limitation, a user interface for an invoice application that includes a drop-down action menu303, a drop-down invoices list305, a task panel307, and a work area309. A user navigates user interface301by selecting an invoice from invoice list305and an action from action menu303. For example, a user selects “Payable Invoices” from action menu303, and tasks “Match Invoice” and “Delete Invoice” appear in task panel307. When user selects “Delete Invoice” in task panel307, “Delete Invoice” button311and “Approve Invoice” button313appear in work area309. Buttons311and313may be securable targets that are, for example, visible but not actionable unless viewed by a role having the privilege to execute the securable targets. A securable target may be a resource such as a web page or page element (e.g., a tab, button, link, text box, etc.), or may be other computational resources such as a file, server, or firewall. Action menu303may also contain submenus. When navigating to a submenu, the menu taken to get to the submenu is referred to as a “parent menu.”

FIG. 4illustrates a flow diagram of the functionality of role navigation designer114in accordance with an embodiment when granting privileges to roles using a navigation path-based model. In one embodiment, the functionality of the flow diagram ofFIG. 4is implemented by software stored in memory and executed by a processor. In other embodiments, the functionality can be performed by hardware, or any combination of hardware and software. Explanation of the functionality is also done with reference to elements ofFIG. 3. A security manager receives a request for a role including privileges that should be granted to the role (400). A role is a set of privileges for an abstract entity, and are created by naming the entity and assigning it privileges. For example, a financial manager may want the privileges to approve and delete invoices. To have these privileges, the financial manager needs access to the target (e.g., a resource such as a file, web page, or page element) that contains the capability to perform these actions. These privileges should be assigned to the “Financial Manager” role. The security manager navigates to a user interface, for example, user interface301, using a menu to find a menu node pointing web page that includes the requested target (410). The security manager may also select specific tasks presented on the web page (420). For example, the security manager may select the “Delete Invoice” task in task panel307to give the Financial Manager role the privilege of deleting invoices. The security manager may also select specific securable page elements, such as a button (430). For example, the security manager may select the “Delete Invoice” button311and “Approve Invoice” button313in work area309. Other securable elements may include menus, links, tasks, tabs, files, text boxes, check boxes, editable text, etc. Access to these securable elements is controlled by the RBAC system. Once the security manager is finished selecting the targets for the requested role (i.e., the menu pages, tasks, and individual securable page elements), the security manager creates a role with a list of privileges that grant access to those targets (440). After creating the role, the security manager may verify the navigability for the role using role navigation verifier116.

FIG. 5illustrates a flow diagram of the functionality of role navigation verifier116in accordance with an embodiment when verifying that a role has access to use the privileges granted to it. In one embodiment, the functionality of the flow diagram ofFIG. 5is implemented by software stored in memory and executed by a processor. In other embodiments, the functionality can be performed by hardware, or any combination of hardware and software. Explanation of the functionality is also done with reference to elements ofFIG. 3. The role navigation verifier116first receives a request to verify that the navigation paths are navigable for the privileges granted to the role (500). Role navigation verifier116then finds the targets associated with the privileges granted to the role (510). For example, the “Delete Invoice” button311is associated with the privilege of deleting invoices granted to a financial manager role. Role navigation verifier116then finds all menu nodes pointing to pages containing the targets (520). Role navigation verifier116then determines the privileges needed to reach the targets through the menu nodes starting with the root menu to the menu node pointing to the target. (530). For each privilege determined at530, role navigation verifier116determines whether the privilege has been granted to the role (540). If a privilege determined at530is not granted to the role, the role is flagged as having an error condition (550). Otherwise the role navigation is verified and the process ends.

Accordingly, a security manager may create a role and assign privileges to that role, or alternatively add privileges to an existing role, by navigating to a target and provisioning the role with access rights to the target in the user interface. The target may be a web page itself or elements of the web page that may be individually secured. The target may also be a file, server, or other computing resource. Once created, the role may be verified by automatically determining the targets for which a role is privileged and automatically determining whether the role has other requisite privileges for navigating to those targets.

Some embodiments of the invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the invention are capable of being distributed as a program product in a variety of forms. The foregoing description of example embodiments is provided for the purpose of illustrating the principles of the invention, and not in limitation thereof, since the scope of the invention is defined solely by the appended claims.