| Oracle® Role Manager User's Guide Release 10g (10.1.4) Part Number E12027-02 |
|
|
View PDF |
| Oracle® Role Manager User's Guide Release 10g (10.1.4) Part Number E12027-02 |
|
|
View PDF |
Oracle Role Manager is an enterprise role management system that provides role lifecycle management capabilities to facilitate the management of business and organizational relationships, roles, and privileges.
Role management systems and provisioning systems are components of an identity management system, along with other components. A role management system, such as Oracle Role Manager, specifies the roles a user has, and a provisioning system ensures that the user has the required access and privileges on operational systems such as Oracle E-Business Suite, PeopleSoft, and Siebel.
This chapter provides an overview of Oracle Role Manager and includes the following topics:
A role is a collection of privileges that are granted to one or more users. Any user who is granted a role is known as a role member. A privilege is a combination of a single permission and a single resource. A permission is a right that enables a role member to perform an action (such as read, or write) on a specified resource (such as an FTP directory or a network printer). For example, if Folder X is a resource and Read is a permission, then Read Folder X is a privilege.
Roles are one of the means to address security risks and adhere to compliance regulations related to identity management.
Keeping information about roles and role assignments up to date across users, organizations, locations, and reporting structures can pose many challenges. By itself, a provisioning system cannot manage and maintain complex business data for multiple hierarchies such as location and reporting hierarchies. However, a role management system such as Oracle Role Manager provides you with the ability to handle complex data across multiple hierarchies, an ability that has traditionally not been offered by provisioning systems. Oracle Role Manager also provides comprehensive reporting features across the lifecycle of enterprise roles.
Oracle Role Manager offers a flexible predefined role model that allows users from the business to manage business policies (through role membership policies) and allows IT team members to manage privilege mappings to roles to ensure users get the appropriate IT access.
A role management system can be used in conjunction with a provisioning system. This is illustrated by the following example:
Suppose an individual joins the Sales team of an organization and the administrator wants to determine the privileges to be assigned to that individual. One approach would be to identify the set of privileges assigned to existing team members and use the provisioning system to individually assign these privileges to the new member. The drawbacks of this approach are:
If the individual's role in the company changes, then the privilege assigned to the individual must be changed manually.
It is difficult to ensure that other individuals hired into the same position are assigned the same set of privileges. This is because the individual was assigned privileges specific to the requirements of the Sales team. There are no designation or grade-level privileges that are common across teams.
IT team members who assign privileges to individuals may not be aware of business policies that do not allow the assignment of privileges to individuals in certain contexts.
An alternative to manually assigning privileges to individuals is to use a role management system for creating roles that abstract these privileges. The role can then be grant to all members of the Sales team. In addition, the administrator can configure rules associated with the role so that when any individual leaves the team, the role management system recalculates the individual's role membership and the provisioning system revokes the privileges that the individual had as a member of the Sales team.
As illustrated by this example, a role management system extends the capabilities of a provisioning system by enabling you to determine privileges based on role memberships.
Oracle Role Manager provides a Web-based user interface for role lifecycle management. Role lifecycle management is a term that describes changes to roles from creation to deletion. It involves creating, modifying, and granting or revoking roles to or from users. Role lifecycle management also includes tracking of role-related information for audit and compliance purposes. Oracle Role Manager enables you to define role membership according to business policies, map roles to users and privileges, and change the state of roles (active state or inactive state) to control access. As mentioned earlier, a role is a set of privileges and all role members get the respective privileges. When business events cause changes in organizational relationships, role memberships are dynamically recalculated to ensure that user access and privileges are in line with business policies. Oracle Role Manager provides to provisioning systems, information about privileges a user belonging to a role must obtain. This is illustrated by the following example:
Suppose there are two departments, Mortgage and Escrow. Using Oracle Role Manager a role administrator creates the roles Mortgage Team Member and Escrow Team Member. All employees belonging to the Mortgage department are automatically granted the Mortgage Team Member role. Similarly, all employees belonging to the Escrow department are automatically granted the Escrow Team Member role.
In addition, the role administrator also configures rules associated with the roles, which enables role memberships to be recalculated whenever there are changes in a relevant organizational relationship. Now, suppose Jane Doe is currently working in the Mortgage department, due to which she is automatically granted the Mortgage Team Member role by Oracle Role Manager. If Jane Doe is transferred to the Escrow department, then Oracle Role Manager revokes the Mortgage Team Member role (by automatically recalculating her role membership) and a provisioning system, such as Oracle Identity Manager, revokes the privileges associated with the Mortgage Team Member role of Jane Doe and then Oracle Role Manager grants Jane Doe the Escrow Team Member role.
Role memberships change as business relationships and policies change. Oracle Role Manager enables provisioning systems to provide users timely access to enterprise information systems by providing accurate role membership information. This ensures that such access is compliant with business regulations and policies.
Oracle Role Manager maintains audit information about roles and role memberships to capture who should have access to what, when, and why. However, a provisioning, system such as Oracle Identity Manager, captures what access a person has.
Oracle Role Manager is a role-based access control (RBAC) system. RBAC is a means of controlling user access to resources in an organization through roles (or role memberships). According to RBAC standards, users are granted access or permissions to resources based on their role grants. Similarly, revoking a role will revoke access or permissions to resources.
Note:
A user can hold more than one role. In other words, a user can be granted memberships to multiple roles.The following points describe the RBAC approach followed by Oracle Role Manager:
Define roles in your organization.
Map a group of privileges to roles.
Grant users membership to roles.
Instead of assigning individual privileges to one user at a time, which can be a cumbersome task, you define a role, map privileges to it, and add users to the defined roles.
Typically, most enterprises have multiple organizational hierarchies such as reporting organization, cost center, and location. Oracle Role Manager manages the data for these multiple hierarchies in the organization. It also manages multiple relationships between hierarchies and users in an organization. Large enterprises require users to work with cross-organizational teams and groups, and this information needs to be captured. To provide an accurate representation of organizational relationships and to maintain data integrity among hierarchies, Oracle Role Manager provides a model known as polyarchy that maps the intersection of multiple, overlapping hierarchies. This feature enables organizations to model complex relationship paths across business structures such as reporting organization hierarchies and locations.
Oracle Role Manager enables organizations to address compliance regulatory requirements such as the Sarbanes-Oxley Act (SOX) and the Health Insurance Portability and Accountability Act (HIPAA).
The features of Oracle Role Manager are as follows:
Context-Aware, Polyarchy-Enabled Role Engine
Oracle Role Manager features a powerful role engine that uses your business policies and the relationships between users and organizations to determine accurate, real-time role membership. This contextually aware, polyarchy-enabled role engine resolves complex relationships across business organizations to ensure that access and privileges are aligned with corporate strategy.
For example, you can specify a cost center manager as a person who is in a Manager role within a cost center hierarchy in your organization . Similarly, you can specify a Europe-based account executive as a person who has a job code or team membership in the sales branch of the reporting hierarchy and who works from the European branch of the location hierarchy.
Authoritative Role and Privilege Repository
Oracle Role Manager aggregates contextual business information, such as organizational relationships, to define role membership. These roles form a comprehensive role repository. Serving as the central source of information for roles, this role repository supplies authoritative privilege-related data to enterprise systems.
Configurable and Extensible Role and Relationship Model
Businesses can have their own, custom-designed organization structures, relationships, and operational models. Oracle Role Manager makes it easy to model unique business structures and relationships by providing a customizable user interface, schema, business login, and so on.
As mentioned in one of the preceding sections, Oracle Role Manager has the reporting organization, cost center and location hierarchies that are predefined in the standard model of Oracle Role Manager. The standard model consists of objects that are required for the Web application of Oracle Role Manager to function as designed. In addition, you can load the sample data that contains sample roles and role definitions, persons, and organizations. See Oracle Role Manager Installation Guide for information about loading sample data.
You can customize the standard model by adding custom attributes and entities depending on the requirements of your business model. You can then add custom business logic to work with your custom objects. See Oracle Role Manager Developer's Guide for more information about customizing the standard data model.
Some business scenarios may require users to delegate access and privileges to other users to distribute role administration across users in an enterprise. By providing features for delegation of role administration, Oracle Role Manager enables users to easily delegate access and privileges without violating business policy. Delegated administration provides business users the ability to manage access and privileges, a function normally performed by IT departments.
For example, a Senior Project Manager who is a business user may choose to delegate role administration of his team to a Project Manager. This enables the Project Manager to manage the access rights and privileges of all team members on behalf of the Senior Project Manager.
Integration with Provisioning Systems
Oracle Role Manager provides an Oracle Role Manager Integration Library (Integration Library) that integrates Oracle Role Manager with provisioning systems such as Oracle Identity Manager. This integration can be used to initiate provisioning events in response to changes in role membership, and business role and IT role mappings.
After integration, whenever a user is created or deleted in Oracle Identity Manager, a corresponding person is created in or deleted from Oracle Role Manager. Similarly whenever a role is created or a role membership is changed in Oracle Role Manager, a corresponding user group is created or the user group membership is changed in Oracle Identity Manager.
Integrating Oracle Role Manager with a provisioning system such as Oracle Identity Manager ensures the following:
Provisioning events occur when role memberships change.
Provisioning events occur when business role and IT role mappings change.
Business events, such as a new hire or transfer, cause role membership to change, which in turn initiates provisioning events.
See Oracle Role Manager Integration Guide for more information about the Integration Library.
Comprehensive Compliance Reporting
Oracle Role Manager captures audit data related to role configuration and role memberships. This data can be manually exported to an audit platform such as Oracle GRC Manager and can be used as evidence of compliance.
By default, every role in Oracle Role Manager is attached to a reporting organization. This means that every role must belong to a reporting organization. The reporting organization to which a role belongs does not limit the scope of role resolution. Oracle Role Manager enables you to set a reporting organization to which the role belongs. This reporting organization states the organization which will be responsible for administering the role definition and role membership.
In other words, setting an organization for a role only states who should administer the role, but does not affect who can be granted this role.
Any role in Oracle Role Manager can be in one of the following statuses:
If a role is inactive, then the Integration Library does not send role membership information to a provisioning system, such as Oracle Identity Manager. You can create and modify role definitions and role memberships without initiating any provisioning events.
If a role is active, then the Integration Library sends information about creation and modification of role definitions and role memberships to a provisioning system such as Oracle Identity Manager.
Oracle Role Manager supports the following types of roles:
A business role is a named collection of business duties or responsibilities that can be granted to users. A business role can be either of a static role type or a dynamic role type. After the role type of a role is defined, the role type cannot be altered.
Business roles are created and managed by business users, such as managers and team leaders. For example, a Regional Manager in the Sales organizational unit can create the Account Executive business role to be granted to employees whose responsibility is to manage new accounts.
Role memberships constantly change in an organization. These changes occur when an employee joins the organization, receives promotion, joins new projects, joins another team, receives a transfer, and so on. With a large number of users and roles, it may be difficult to ensure that users have the right roles at the right time to fulfill their work responsibilities. To address this challenge, Oracle Role Manager provides a feature called dynamic business roles.
The following business roles are discussed in this section:
Dynamic business roles depend on rules (membership rules) to determine role memberships. Membership rules define who must be granted a particular role under what circumstances. For example, a business user can create a membership rule to grant the Senior Accountant business role to all users in the Accounting reporting hierarchy whose job title is Manager. All users in the Accounting reporting organization who meet the condition described by this membership rule are automatically added to the membership list of the Senior Accountant role. A membership list for a role is a set of all users who have been granted that particular role.
Figure 1-1 illustrates another example of a dynamic business role.
Figure 1-1 Organization Structure Used for a Sample Dynamic Business Role Membership
Consider the Bank_Teller_UK dynamic business role. This role uses the membership rule that states that all users whose office location is within the UK office hierarchy and employee type is Bank Staff will automatically be granted the Bank_Teller_UK role.
As shown in Figure 1-1, Fred and Jane are granted this role because they meet the criterion specified in the preceding paragraph. However, Joe and Mary, whose employee type is Bank Staff, are not granted this role because they do not belong to the UK office hierarchy. In addition, if Jane's employee type changes to IT Staff, then the Bank_Teller_UK role is automatically revoked because she no longer satisfies the membership rule criterion.
As illustrated by this example, dynamic business roles help maintain role membership accuracy because memberships to these roles are automatically determined in response to business events, such as promotion or change in office location. In addition, if the membership rule of a dynamic business role is modified, then the membership list of this role will be recalculated using the modified membership rule.
Static business roles determine role membership through manual role grants. Unlike dynamic business roles, which use membership rules, static business roles must be granted manually to one user at a time. They do not depend on rules that define who must be granted a particular role.
For example, consider the static business role Accounting Clerk. If John, an Accounting Manager decides to grant this role to his team member David, then John must manually grant this role to David. Similarly, when David moves to a different team or a role, John must manually revoke this role from David.
A static business role may also be associated with an eligibility rule. An eligibility rule enables you to filter the list of users to whom you want to manually grant roles. In other words, an eligibility rule shortlists all the users who are eligible to be granted a static business role. For example, consider the Payroll Analyst static business role with the View and Edit Payroll privilege, which is a special privilege. To closely monitor access to this privilege, you can choose to grant this role manually. In addition, you can create an eligibility rule that states that the Payroll Analyst static business role can only be granted to users who belong to the payroll team. When someone tries to grant the Payroll Analyst static business role to a person who does not belong to the payroll team, the grant fails. In other words, the eligibility rule does not allow this role to be granted to users who are not members of the payroll team.
Note:
An eligibility rule will prevent a role grant whenever the person being granted the role does not meet the requirements of the rule. Also note that eligibility rules do not automate role memberships.An eligibility rule is enforced only at the time of grant. For example, suppose Max has been granted the Project_Manager_Europe static business role. This role is associated with the MS_Access_UK privilege, which translates into an account on the Microsoft Access installation in Manchester, UK. The eligibility rule associated with this privilege is that the individual to whom the privilege is assigned must be a manager in any of the European offices of the organization. Now, suppose Max is transferred to the San Francisco office. The Project_Manager_Europe role is not automatically revoked from Max in response to this business event. In other words, Max's eligibility to be granted the Project_Manager_Europe role is checked only before he is granted the role, and not at any other time.
You can create static business roles with a sphere of control (SOC), which is a relationship between a grant and a node within a hierarchy such as reporting, cost center, and location. In other words, SOC specifies the organizational scope (hierarchy or a node within a hierarchy) within which a grantee can exercise a role. A grantee is a person to whom a role has been granted.
SOC is a means of limiting the validity of a grant within a hierarchy.
Figure 1-2 illustrates a location hierarchy along with the Linux Admin static business role that is granted to John Doe.
Figure 1-2 Static Business Role with Sphere of Control
The Linux Admin static business role is granted to John with the SOC set to the London office (which is a node) in the Location hierarchy. This means that John has this role only when he is in the London office. This role is not valid if John moves to the Munich office.
Static business roles enable you to handle special and high-value privileges and ensure that the system does not automatically grant access to such privileges.
You can choose to grant static business roles if you are in a situation where no appropriate rule has been (or can be) defined, yet there is a need for grouping users according to a single business context.
An IT role is a named collection of IT privileges that can be granted to users. Any privilege for an external application that associates itself with an IT resource is known as an IT privilege. For example, if a router is an IT resource and Configure is a permission, then Configure Router is an IT privilege.
You can map IT roles to business roles in order to grant users a set of privileges.
Figure 1-3 illustrates an example of an IT role mapped to a business role.
Figure 1-3 Sample Mapping of IT Role to Business Role: Scenario 1
As illustrated in Figure 1-3, the Inventory System Administrator IT role is a collection of IT privileges: Create Inventory System Accounts, Modify Inventory System Accounts, and Delete Inventory System Accounts. This IT role is mapped to the business role Production Engineer, which is granted to John. Because John is a member of the business role Production Engineer, he is also automatically a member of the related Inventory System Administrator IT role. Therefore, John gets all the privileges that are mapped to the Inventory System Administrator IT role.
In addition to mapping IT roles to a business role for granting users a set of IT privileges, a you can directly grant an IT role to a user. Figure 1-4 extends the scenario described in Figure 1-3.
Figure 1-4 Sample Mapping of IT Role to Business Role: Scenario 2
As illustrated in Figure 1-4, John is granted the Production Engineer business role. This business role has the Inventory System Administrator IT role, which is a collection of the Create Inventory System Accounts, Modify Inventory System Accounts, and Delete Inventory System Accounts IT privileges. This implies that John automatically has membership to the Inventory System Administrator IT role. Therefore, John gets all the privileges that are mapped to the Inventory System Administrator IT role.
Mary, who is another user, also has membership to the Inventory System Administrator IT role though she is not a member of the Production Engineer business role. This is because Mary is directly granted the Inventory System Administrator IT role.
If a user is no longer a member of a particular business role, then that user will automatically lose membership to related IT roles. However, it is possible that a user may have two business roles, both of which are mapped to the same IT role. In such a scenario, the user will not lose membership of the IT role unless the user loses membership of both business roles. Figure 1-5 illustrates this scenario.
Figure 1-5 Sample Mapping of IT Role to Business Role: Scenario 3
As shown in Figure 1-5, John has been granted another business role, Factory Supervisor, which is mapped to the Leave Approver and Inventory System Administrator IT roles as illustrated in Figure 1-5. The Leave Approver IT role has the View Leave Requests and Approve Leave Requests IT privileges on the HR system. The Inventory System Administrator IT role has the Create Inventory System Accounts, Modify Inventory System Accounts, and Delete Inventory System Accounts IT privileges. Therefore, mapping of the Leave Approver and Inventory System Administrator IT roles to the Factory Supervisor business role results in the IT privileges of all IT roles (mapped to the business role) being applied to John, who is a member of the Factory Supervisor business role.
Now, suppose John loses the Production Engineer business role. However, John does not automatically lose the related Inventory System Administrator IT role. This is because John is granted the Factory Supervisor business role that has the Inventory System Administrator IT role as one of its IT roles. John will not lose the membership to the Inventory System Administrator IT role unless he loses memberships to both the business roles granted to him.
Typically, IT roles are managed by IT teams. It is recommended that IT team members provide descriptive data about the IT role because the IT privilege names (from external systems) may be cryptic. This may give no indication to the business user about the kind of access being granted to a user.
Providing descriptive information about an IT role enables business users to decide if the IT role should be mapped to a business role. For example, an IT team member can enter the following description for the Inventory System Administrator IT Role:
This role will give users the ability to create, edit, and modify inventory system accounts.
Therefore, IT roles can be understood at a high level by business users also.
IT roles often group all privileges from a single resource. For example, consider the IT role Outlook E-mail Access, which contains privileges such as Create E-mail, Send E-mail, Delete E-mail, and Create Calendar Entry. These privileges belong to a single resource, which is the Outlook e-mail server.
Note:
Although it is possible to group privileges from multiple resources into a single IT role, Oracle recommends grouping privileges only from a single resource in an IT role. This is because it is easier to manage an IT role containing privileges from a single resource.You can map an IT role to one or more business roles. For example, the E-mail Access IT role can be mapped to business roles such as Sales Manager, Accounts Manager, and HR Manager. However, it is recommended to directly grant an IT role to a user than to grant a business role with a single IT role.
An approver is a person who is responsible for authorizing a workflow request or even a single step within a multiple-step workflow request, in a system other than Oracle Role Manager. An approver role is a collection of approvers. In other words, an approver role is a container that holds approvers.
Approver roles are dynamic in nature. Therefore, they use membership rules similar to dynamic business roles.
For example, you can create a membership rule to determine the person who approves the CRM application access request for a person John Doe. When you run this rule, John Doe (the subject of the rule) is found along with the person who has a Manager relationship with John Doe.
Identifying the approvers for workflow routing (which is done by an external application) is complex because it requires more organizational data than a provisioning system can typically store and manage. Approver roles are a unique concept of Oracle Role Manager, to leverage the polyarchy data for use with external workflow systems.
Provisioning and access management products include the names of the approvers in their approval workflow itself. This way, you need multiple workflows for the same privilege because you must include different approvers for different organizational units and functional groups within the approval workflow. Because approvers are directly included in workflows, the workflows lack business context and become out of date whenever an approver leaves or the approval rule changes.
Oracle Role Manager enables you to define membership rules and to determine approvers by navigating various organizational and relationship hierarchies.
A system role is a named collection of system privileges related to your current installation of Oracle Role Manager. A system privilege is a combination of a single object and one or more system permissions. A system permission is a right that enables access to an object (or a system resource). For example, if a business role is an object and Manage is a permission, then Manage Business Role objects is a system privilege.
System privileges are created during Oracle Role Manager installation. You cannot add, modify, or delete system privileges. System privileges are mapped to system roles to represent that the members of that system role have system permissions with respect to objects or the system resource (in this case, Oracle Role Manager).
A system role defines the kind of access to Oracle Role Manager a user has. A system role also determines if you have the privileges required to modify other system roles.
System roles are containers for system privileges. Objects (such as Business Role objects, IT privilege objects, Country objects, and Person objects) can have Audit, Delegate, Grant, and Manage as system permissions. For example, the Role Administrator system role can have the Manage Approver Role objects, All for IT Role objects, and Delegate Business Role objects system privileges.
Note:
By default, every user in Oracle Role Manager has read permission on all objects.System roles are static in nature. System roles can be granted to persons or system identities. System Identities are system user objects that are created in order to access the Oracle Role Manager system. System Identities normally represent external systems, such as a user provisioning system that accesses Oracle Role Manager for role resolution, workflows, or access provisioning.
You must individually grant system roles to users of Oracle Role Manager or system identities. For example, you can define users who must have delegate access for certain objects in the Oracle Role Manager user interface, and grant access for some other objects of the user interface. System roles are the means for enforcing internal security for Oracle Role Manager.
Figure 1-6 illustrates an example of system privileges mapped to a system role that is granted to a user John.
Figure 1-6 Sample Mapping of System Privileges to a System Role
As illustrated in Figure 1-6, the Role Administrator system role is a collection of the Manage IT Role objects, Manage Business Role objects, and Audit IT Privilege objects system privileges. The Role Administrator system role is granted to John. Therefore, with the manage system permission for IT role and business role objects, John can create, update, and delete IT roles and business roles. With the Audit IT Privilege objects system role, John can read all information related to IT privileges.
System roles support the concept of sphere of control (similar to static business roles) by defining the hierarchy within which the role is valid. You can grant system roles to Oracle Role Manager users with SOC.
Figure 1-7 illustrates an example of a system role granted to John with SOC.
Figure 1-7 Sample Scenario Depicting a System Role Grant with SOC
Suppose John belongs to the Accounting reporting organization. As illustrated in Figure 1-7, John is granted the User Administrator system role with an SOC set on the Accounting reporting organization. The All for Person objects system privilege is mapped to the User Administrator system role. This means that, John can create, update, and delete person records that belong to the Accounting reporting organization and all its child organizations.
Now, suppose John is moved from the Accounting reporting organization to the Office of the COO organization. John will still be able to create, update, and delete person records that belong to the Accounting reporting organization and all its child organizations such as the Consumer Banking, Commercial Banking and Branch Operation reporting organizations. This is because, John has been granted the User Administration system role with SOC set on the Accounting reporting organization. The organization to which a person belongs is orthogonal to the organizations over which the person is granted SOC.
System privileges and the System Administrator system role are defined during Oracle Role Manager installation. In addition, system roles can be created, modified, or deleted according to your requirements. See "Predefined System Roles" for information about predefined system roles that are available in addition to the system roles that are available as part of the sample data.
|
 Copyright © 2007, 2008, Oracle. All rights reserved. Legal Notices |
|
