2Managing Roles
Managing Roles in Public Sector Compliance and Regulation
This topic introduces roles are use to implement security and the general Oracle Cloud security role types. It also highlights key roles and configuration considerations to keep in mind when implementing Public Sector Compliance and Regulation.
Role-Based Access Control
When you receive your Oracle Cloud application, access to its functionality and data is secured using the industry-standard framework for authorization, role-based access control. In a role-based access control model, users are assigned roles, and roles are assigned access privileges to protected resources. The relationship between users, roles, and privileges is shown in the following figure.
Users gain access to application data and functions when you assign them roles, which correspond to the job functions in your organization or the functions a citizen in your municipality may perform.
Users can have any number of different roles concurrently, and this combination of roles determines the user's level of access to protected system resources. For example, a user might be assigned the Agency Staff role, the Permits Supervisor role, and the Permits Application Administrator role. In this case, the user has the following access:
With the Agency Staff role, the user can access functions and data suitable for agency staff members.
With the Permits Supervisor role, the user can access permits manager functions and data, and access and correct permit technician functions and data.
With the Permits Application Administrator role, the user can access permit configuration settings and make necessary changes.
When the user logs into Oracle Cloud and is successfully authenticated, a user session is established and all the roles assigned to the user are loaded into the session repository. Oracle Cloud determines the set of privileges to application resources that are provided by the roles, then grants the user the most permissive level of access.
Role Types
Oracle Cloud defines the following types of roles:
Role Type |
Description |
---|---|
Job Roles |
Job roles represent the jobs that users perform in an organization. General Accountant and Accounts Receivables Manager are examples of predefined job roles. You can also create job roles. |
Abstract Roles |
Abstract roles represent people in the enterprise independently of the jobs they perform. Some predefined abstract roles in Oracle Applications Cloud include Employee and Transactional Business Intelligence Worker. You can also create abstract roles. All users are likely to have at least one abstract role that provides access to a set of standard functions. You may assign abstract roles directly to users. |
Duty Roles |
Duty roles represent a logical collection of privileges that grant access to tasks that someone performs as part of a job. Budget Review and Account Balance Review are examples of predefined duty roles. You can also create duty roles. Other characteristics of duty roles include:
Job and abstract roles may inherit duty roles either directly or indirectly. You don't assign duty roles directly to users. |
Aggregate Privileges |
Aggregate privileges are roles that combine the functional privilege for an individual task or duty with the relevant data security policies. Functions that aggregate privileges might grant access to include task flows, application pages, work areas, dashboards, reports, batch programs, and so on. Aggregate privileges differ from duty roles in these ways:
You can include the predefined aggregate privileges in your job and abstract roles. You assign aggregate privileges to these roles directly. You don't assign aggregate privileges directly to users. |
Duty Role Elements
Functional security privileges and data security policies are granted to duty roles. Duty roles may also inherit aggregate privileges and other duty roles.
Elements |
Description |
---|---|
Data Security Policies |
For a given duty role, you may create any number of data security policies. Each policy selects a set of data required for the duty to be completed and actions that may be performed on that data. The duty role may also acquire data security policies indirectly from its aggregate privileges. Each data security policy combines:
|
Function Security Privileges |
Many function security privileges are granted directly to a duty role. It also acquires function security privileges indirectly from its aggregate privileges. Each function security privilege secures the code resources that make up the relevant pages, such as the Manage Grades and Manage Locations pages.
Tip: The predefined duty roles represent logical groupings of privileges that you may want to manage as a group. They also represent real-world groups of tasks. For example, the predefined General Accountant job role inherits the General Ledger Reporting duty role. To create your own General Accountant job role with no access to reporting structures, you could copy the predefined job role and remove the General Ledger Reporting duty role from the role hierarchy.
|
Aggregate Privileges
Aggregate privileges are a type of role. Each aggregate privilege combines a single function security privilege with related data security policies. All aggregate privileges are predefined. This topic describes how aggregate privileges are named and used.
Aggregate Privilege Names
An aggregate privilege takes its name from the function security privilege that it includes. For example, the Manage Accounts Payable Accounting Period Status aggregate privilege includes the Manage Accounting Period Status function security privilege.
Aggregate Privileges in the Role Hierarchy
Job roles and abstract roles inherit aggregate privileges directly. Duty roles may also inherit aggregate privileges. However, aggregate privileges can't inherit other roles of any type. As most function and data security in job and abstract roles is provided by aggregate privileges, the role hierarchy has few levels. This flat hierarchy is easy to manage.
Use of Aggregate Privileges in Custom Roles
You can include aggregate privileges in the role hierarchy of a custom role. Treat aggregate privileges as role building blocks.
Creating, Editing, or Copying Aggregate Privileges
You can't create, edit, or copy aggregate privileges, nor can you grant the privileges from an aggregate privilege to another role. The purpose of an aggregate privilege is to grant a function security privilege only in combination with a specific data security policy. Therefore, you must use the aggregate privilege as a single entity.
If you copy a job or abstract role, then the source role's aggregate privileges are never copied. Instead, role membership is added automatically to the aggregate privilege for the copied role.
Understanding Role Hierarchies and Inheritance
Almost every role is a hierarchy or collection of other roles.
Job and abstract roles inherit aggregate privileges. They may also inherit duty roles.
In addition to aggregate privileges and duty roles, job and abstract roles are granted many function security privileges and data security policies directly. You can explore the complete structure of a job or abstract role in the Security Console.
Duty roles can inherit other duty roles and aggregate privileges.
When you assign roles, users inherit all of the data and function security associated with those roles.
In Oracle Cloud, each role can be linked to other roles in a parent-child format to form a hierarchy of roles. As illustrated in the following figure, users are assigned job and abstract roles, which inherit duty roles and their associated privileges. Duty roles in turn can inherit privileges from subordinate duty roles. You can explore the complete structure of a job or abstract role on the Security Console.
Role hierarchies allow privileges to be grouped to represent a feature set in Oracle Cloud, which simplifies feature management. Role hierarchies also provide privilege granularity and facilitate role reuse. For example, each role hierarchy beneath the job role represents a feature that is available through the job role to the user. Roles at lower levels of the hierarchy represent functionality that the feature requires. If this functionality is required by other features, the role that provides the functionality can be shared across roles.
In the previous example, assume an inspection supervisor, Grady Parker.
Because Grady is employed by the agency, he is assigned the Agency Staff abstract role, and at least one job role, which is in the is case Inspection Supervisor.
Through the Inspection Supervisor job role, Grady inherits a set of duty roles, including the Inspection Request Management duty role. There is also a privilege unique to inspection supervisors, Access Supervisor Calendar, which is assigned directly to the job role.
The Inspection Request Management duty role contains other duty roles as well as a set of inherited aggregate privileges, including Cancel Inspection Requests and Schedule Inspections.
The Cancel Inspection Requests aggregate privilege is comprised of both a function security policy and data security policy.
Predefined Roles for Public Sector Compliance and Regulation
Public Sector Compliance and Regulation provides a set of predefined top-level roles that you can assign to users or clone to create additional roles. Oracle Cloud refers to the top-level roles in the system as top roles, because these are the roles at the top of the role hierarchy. Top roles can be job roles or abstract roles.
The following table lists a sample of the top roles in the Public Sector Compliance and Regulation service.
Role |
Role Type |
Description |
---|---|---|
PSC Agency Staff |
Abstract |
Provides default privileges for any agency staff employee. |
PSC Registered Public User |
Abstract |
Provides default privileges for any end user who has completed the self registration process. |
PSC Building Inspector |
Job |
An agency staff position responsible for inspecting sites for permit approval. |
PSC Business Analyst |
Job |
A staff member that supports the agency in implementing and maintaining the applications. |
PSC Cashier |
Job |
Responsible for the sale and record keeping for various licenses and permits. |
PSC Chief Building Officer |
Job |
Manages a staff of permit technicians and inspectors. Oversees that the staff processes permits expeditiously and accurately and that all fees are collected and accounted. |
PSC Economic Development Officer |
Job |
Maintains various ledgers, registers, and journals according to established account classifications. Audits fees against department activity, researches discrepancies, and performs accounting clerical work. |
PSC Finance Administrator |
Job |
Reviews all incoming permit applications for accuracy and checks for any needed supporting documentation. Reviews the checklist to determine if they need further review or routing to other departments. |
PSC Geographical Information System Administrator |
Job |
Uses Geographical Information System software and related programs for provision of maps, charts, graphs, and other related information for visual displays, presentations or reports. |
PSC Inspections Supervisor |
Job |
Manages the workflow and staff to get through inspection jobs everyday. Keeps track of inspectors, districts and workload. |
PSC Permit Technician |
Job |
Performs permit technician duties, which includes processing applications, fee assessments, fee collections, documents, standardization, and permit issuance. |
PSC Permits Application Administrator |
Job |
An agency staff position that oversees the permit application. |
PSC Permits Supervisor |
Job |
Manages the workflow and staff to ensure that the permit applications are assigned and processed by the permit technicians. |
PSC Plan Reviewer |
Job |
Reviews plans for development, modification, alteration and demolition of commercial and residential properties. Checks compliance with applicable state and local zoning and building codes and related regulations. Calculates fees required for issuance of permits. |
PSC Planning Coordinator |
Job |
Coordinates plan review, permitting, and inspection of private construction projects in accordance with municipal ordinances and adopted building codes and code enforcement. |
PSC Principal Planner |
Job |
Reviews construction plans for compliance with all state and local development and zoning codes, regulations, and requirements. |
PSC System Administrator |
Job |
An agency staff position that has all access to configuration settings, security settings, and is able to access and solve issues for other users. |
The remainder of the delivered roles are lower-level child roles that group privileges and link privileges to the top-level roles.
Key Duty Roles in Public Sector Compliance and Regulation
The following table highlights a set of key duty roles to illustrate some delivered, predefined duty roles.
Duty Role |
Description |
---|---|
PSC Apply Permit |
Provides all the access required for an applicant, such as being able to access a permit, fill in and submit a permit application, add comments to the permit during the application process, and so on. |
PSC Agency Permits Inquiry |
Provides the read only access for the agency staff members so that they can review and process permit applications. |
PSC Anonymous Permit Application Inquiry |
Provides read-only access for viewing a permit application.
Note: Oracle Fusion Applications do not allow modification of any anonymous roles.
|
Working with Aggregate Privileges in Public Sector Compliance and Regulation
All aggregate privileges are predefined. Aggregate privileges combine a single functional security privilege with related data security policies.
In many cases with roles in the Public Sector Compliance and Regulation Cloud, you see a pattern, where one aggregate role provides the general, default behavior, such as allowing a user to insert comments and update only their own comments. Then there is a counterpart aggregate role that would provide more far reaching privileges, such as updating the comments for others.
For example, consider these aggregate roles:
PSC Update Inspection Comments added by self
PSC Update Inspection Attachments added by self
PSC Update Inspection Comments added by others and self
PSC Update Inspection Attachments added by others and self
For example, with the comments and attachments, most roles provide you with the ability to add comments or attachments and update comments or attachments inserted by yourself. However, by assigning to the user another aggregate role (with the phrase “by others and self” in the role title), that user could update comments or attachments added by others. A supervisor in the permit processing department could update comments in a permit added by one of their permit technicians if they have the following role assigned to their user account: PSC Update Inspection Comments added by others and self.
By default, the ”by others and self” aggregate privileges are assigned only to system administrators.
Modifying Delivered Roles
If the delivered top roles do not meet your business requirements, you can create custom roles by cloning a delivered job or abstract role, and then modifying the custom role as needed. When cloning a role, this also copies the role hierarchy, which you can modify as needed by either adding or removing elements of the hierarchy.
When creating custom roles, it is highly recommended to modify a role’s access through aggregate privileges, rather than attempting to modify a job, abstract, or duty role manually. Modifying access using aggregate privileges is efficient and a more robust approach. Keep in mind that aggregate privileges contain both the functional security and the data security policy for an action. By adding or removing an aggregate privilege, you make one change, but adjust both aspects of security simultaneously. If you update a duty role manually, you will need to always make sure you’ve added or removed the functional and data security counterparts. Otherwise, you may not be providing or restricting the access you intend, while in other cases, you may be creating security holes, unintentionally.
Working with Roles in the Security Console
This topic describes the tasks associated with roles that you complete using the Security Console.
You can use the Security Console to perform a variety of tasks related to roles, including:
View the roles assigned to a user.
Identify users who have a specific role.
Copying existing roles.
Create duty, job, or abstract roles.
You must have the IT Security Manager job role to perform these tasks.
Viewing the Roles Assigned to a User
Open the Security Console.
On the Roles tab, search for and select the user.
Depending on the enterprise setting, either a table or a graphical representation of the user's role hierarchy appears. Switch to the graphical representation if necessary to see the user and any roles that the user inherits directly. User and role names appear on hover. To expand an inherited role:
Select the role and right-click.
Select Expand. Repeat these steps as required to move down the hierarchy.
Tip: Switch to the table to see the complete role hierarchy at once. You can export the details to Microsoft Excel from this view.
Identifying Users Who Have a Specific Role
On the Roles tab of the Security Console, search for and select the role.
Depending on the enterprise setting, either a table or a graphical representation of the role hierarchy appears. Switch to the graphical representation if it doesn't appear by default.
Set Expand Toward to Users.
Tip: Tip: Set the Expand Toward option to control the direction of the graph. You can move either up the hierarchy from the selected role (toward users) or down the hierarchy from the selected role (toward privileges).In the refreshed graph, user names appear on hover. Users may inherit roles either directly or indirectly from other roles. Expand a role to view its hierarchy.
In the Legend, click the Tabular View icon for the User icon. The table lists all users who have the role. You can export this information to Microsoft Excel.
Reviewing Role Hierarchies
On the Security Console you can review the role hierarchy of a job role, an abstract role, or a duty role.
On the Roles tab of the Security Console, ensure that Expand Toward is set to Privileges.
Search for and select the role. Depending on the enterprise setting, either a table or a graphical representation of the role appears.
If the table doesn't appear by default, click the View as Table icon. The table lists every role inherited either directly or indirectly by the selected role. Set Show to Privileges to switch from roles to privileges.
Tip: Enter text in a column search field and press Enter to show only those roles or privileges that contain the specified text
Click Export to Excel to export the current table data to Microsoft Excel.
Comparing Roles
You can compare any two roles to see the structural differences between them. As you compare roles, you can also add function and data security policies existing in the first role to the second role, providing that the second role is not a predefined role.
For example, assume you have copied a role and edited the copy. You then upgrade to a new release. You can compare your edited role from the earlier release with the role as shipped in the later release. You may then decide whether to incorporate upgrade changes into your edited role. If the changes consist of new function or data security policies, you can upgrade your edited role by adding the new policies to it.
Select the Roles tab in the Security Console.
Do any of the following:
Click the Compare Roles button.
Create a visualization graph, right-click one of its roles, and select the Compare Roles option.
Generate a list of roles in the Search Results column of the Roles page. Select one of them, and click its menu icon. In the menu, select Compare Roles.
Select roles for comparison:
If you began by clicking the Compare Roles button, select roles in both First Role and Second Role fields.
If you began by selecting a role in a visualization graph or the Search Results column, the First Role field displays the name of the role you selected. Select another role in the Second Role field.
For either field, click the search icon, enter text, and select from a list of roles whose names contain that text.
Select two roles for comparison.
Use the Filter Criteria field to filter for any combination of these artifacts in the two roles:
Function security policies
Data security policies
Inherited roles
Use the Show field to determine whether the comparison returns:
All artifacts existing in each role
Those that exist only in one role, or only in the other role
Those that exist only in both roles
Click the Compare button.
You can export the results of a comparison to a spreadsheet. Select the Export to Excel option.
After you create the initial comparison, you can change the filter and show options. When you do, a new comparison is generated automatically.
Adding Policies to a Role
Select two roles for comparison.
As the First Role, select a role in which policies already exist.
As the Second Role, select the role to which you are adding the policies. This must be a custom role. You cannot modify a predefined role.
Ensure that your selection in the Filter Criteria field excludes the Inherited roles option. You may select Data security policies, Function security policies, or both.
As a Show value, select Only in first role.
Click the Compare button.
Among the artifacts returned by the comparison, select those you want to copy.
An Add to Second Role option becomes active. Select it.
Custom Role Considerations
In many cases, an efficient method of creating a role is to copy an existing role, then edit the copy to meet your requirements. Typically, you would create a role from scratch if no existing role is similar to the role you want to create.
To create a role from scratch, select the Roles tab in the Security Console, then click the Create Role button. Enter values in a series of role-creation pages, selecting Next or Back to navigate among them.
Providing Basic Information
On a Basic Information page:
In the Role Name field, create a display name, for example North America Accounts Receivable Specialist.
In the Role Code field, create an internal name for the role, such as AR_NA_ACCOUNTS_RECEIVABLE_SPECIALIST_JOB.
Note: Do not use "ORA_" as the beginning of a role code. This prefix is reserved for roles predefined by Oracle. You cannot edit a role with the ORA_ prefix.In the Role Category field, select a tag that identifies a purpose the role serves in common with other roles. Typically, a tag specifies a role type and an application to which the role applies, such as Financials - Job Roles.
If you select a duty-role category, you cannot assign the role you are creating directly to users. To assign it, you would include it in the hierarchy of a job or abstract role, then assign that role to users.
Optionally, describe the role in the Description field.
Adding Function Security Policies
A function security policy selects a set of functional privileges, each of which permits use of a field or other user-interface feature. On the Function Security Policies page, you may define a policy for:
A duty role. In this case, the policy selects functional privileges that may be inherited by duty, job, or abstract roles to which the duty is to belong.
A job or abstract role. In this case, the policy selects functional privileges specific to that role.
As you define a policy, you can either add an individual privilege or copy all the privileges that belong to an existing role:
Select Add Function Security Policy.
In a Search field, select the value Privileges or types of role in any combination and enter at least three characters. The search returns values including items of the type you selected, whose names contain the characters you entered.
Select a privilege or role. If you select a privilege, click Add Privilege to Role. If you select a role, click Add Selected Privileges.
The Function Security Policies page lists all selected privileges. When appropriate, it also lists the role from which a privilege is inherited. You can:
Click a privilege to view details of the code resource it secures.
Delete a privilege. You may, for example, have added the privileges associated with a role. If you want to use only some of them, you must delete the rest. To delete a privilege, click its x icon.
Configuring the Role Hierarchy
A Role Hierarchy page displays either a visualization graph, with the role you are creating as its focus, or a visualization table. Select the Show Graph button or View as Table button to select between them. In either case, link the role you are creating to other roles from which it is to inherit function and data security privileges.
If you are creating a duty role, you can add duty roles or aggregate privileges to it. In effect, you are creating an expanded set of duties for incorporation into a job or abstract role.
If you are creating a job or abstract role, you can add aggregate privileges, duty roles, or other job or abstract roles to it.
To add a role:
Select Add Role.
In a Search field, select a combination of role types and enter at least three characters. The search returns values including items of the type you selected, whose names contain the characters you entered.
Select the role you want, and click Add Role Membership. You add not only the role you have selected, but also its entire hierarchy.
In the graph view, you can use the visualization Control Panel, Legend, and Overview tools to manipulate the nodes that define your role hierarchy.
Adding Users to Roles
On a Users page, you can select users to whom you want to assign a job or abstract role you are creating. (You cannot assign a duty role directly to users.)
To add a user:
Select Add User.
In a Search field, select the value Users or types of role in any combination and enter at least three characters. The search returns values including items of the type you selected, whose names contain the characters you entered.
Select a user or role. If you select a user, click Add User to Role. If you select a role, click Add Selected Users; this adds all its assigned users to the role you are creating.
The Users page lists all selected users. You can delete a user. You may, for example, have added all the users associated with a role. If you want to assign your new role only to some of them, you must delete the rest. To delete a user, click its x icon.
Copying and Editing Roles
Rather than create a role from scratch, you can copy a role, then edit the copy to create a new role. Or you can edit existing custom roles.
Initiate a copy or an edit from the Roles tab in the Security Console. Do either of the following:
Create a visualization graph and select any role in it. Right-click and select Copy Role or Edit Role.
Generate a list of roles in the Search Results column of the Roles page. Select one of them, and click its menu icon. In the menu, select Copy Role or Edit Role.
If you are copying a role, select one of two options in a Copy Option dialog:
Copy role: You copy only the role you have selected. The source role has links to roles in its hierarchy, and the copy inherits links to the original versions of those roles. If you select this option, subsequent changes to the inherited roles affect not only the source highest role, but also your copy.
Copy role and inherited roles: You copy not only the role you have selected, but also all of the roles in its hierarchy. Your copy of the highest role is connected to the new copies of subordinate roles. If you select this option, you insulate the copied role from changes to the original versions of the inherited roles.
Next, an editing train opens. You follow the same process in editing a role as you would to create one. However, note the following:
In the Basic Information page, a Predefined role box is checked if you selected the Edit Role option for a role shipped by Oracle. In that case, you can:
Add custom data security policies. Modify or remove those custom data security policies.
Add or remove users if the role is a job, abstract, or discretionary role.
You cannot:
Modify, add, or remove function security policies.
Modify or remove data security policies provided by Oracle.
Modify the role hierarchy.
The Predefined role check box is cleared if you are editing a custom role or if you have copied a role. In that case, you can make any changes to role components.
By default, the name and code of a copied role match the source role's, except a prefix, suffix, or both are appended. In the Roles Administration page, you can configure the default prefix and suffix for each value.
A copied role cannot inherit users from a source job or abstract role. You must select users for the copied role. (They may include users who belong to the source role.)
When you copy a role, the Role Hierarchy page displays all roles subordinate to it. However, you can add roles only to, or remove them from, the highest role you copied.
To monitor the status of a role-copy job, select the Administration tab, and then the Role Copy Status tab of the Administration page.
Copying a Top Role
When you copy a role on the Security Console, you select one of the following options:
Copy top role
Copy top role and inherited roles
If you select the Copy top role option, then only the top role from the selected role hierarchy is copied. Memberships are created for the copy in the roles of which the original is a member. That is, the copy of the top role references the inherited role hierarchy of the source role. Any changes made to those inherited roles appear in both the source role and the copy. Therefore, you must take care when you edit the role hierarchy of the copy. You can:
Add roles directly to the copy without affecting the source role.
Remove any role from the copy that it inherits directly without affecting the source role. However, if you remove any role that's inherited indirectly by the copy, then any role that inherits the removed role's parent role is affected.
Add or remove function and data security privileges that are granted directly to the copy of the top role.
If you copy a custom role and edit any inherited role, then the changes affect any role that inherits the edited role.
The option of copying the top role is referred to as a shallow copy, where the copy references the same instances of the inherited roles as the source role. No copies are made of the inherited roles.
The option of copying the top role is referred to as a shallow copy. This figure summarizes the effects of a shallow copy. It shows that the copy references the same instances of the inherited roles as the source role. No copies are made of the inherited roles.
You're recommended to create a shallow copy unless you must make changes that could affect other roles or that you couldn't make to predefined roles. To edit the inherited roles without affecting other roles, you must first make copies of those inherited roles. To copy the inherited roles, select the Copy top role and inherited roles option.
Copy a Top Role and the Inherited Roles
Selecting Copy top role and inherited roles is a request to copy the entire role hierarchy. These rules apply:
Inherited aggregate privileges are never copied. Instead, membership is added to each aggregate privilege for the copy of the source role.
Inherited duty roles are copied if a copy with the same name doesn't already exist. Otherwise, membership is added to the existing copies of the duty roles for the new role.
When inherited duty roles are copied, custom duty roles are created. Therefore, you can edit them without affecting other roles. Equally, changes made subsequently to the source duty roles don't appear in the copies of those roles. For example, if those duty roles are predefined and are updated during upgrade, then you may have to update your copies manually after upgrade.
This option is referred to as a deep copy, where copies of the inherited duty roles with the same name don't already exist. Therefore, the inherited duty roles are copied when you copy the top role. Aggregate privileges are referenced from the new role.
Copying Job and Abstract Roles
You can copy any job role or abstract role and use it as the basis for a custom role. Copying roles is more efficient than creating them from scratch, especially if your changes are minor.
On the Roles tab of the Security Console, search for the role to copy.
Select the role in the search results. The role hierarchy appears in tabular format by default.
Tip: Tip: Click the Show Graph icon to show the hierarchy in graphical format.In the search results, click the down arrow for the selected role and select Copy Role.
In the Copy Options dialog box, select a copy option.
Click Copy Role.
On the Copy Role: Basic Information page, review and edit the Role Name, Role Code, and Description values, as appropriate.
Tip: The role name and code have the default prefix and suffix for copied roles specified on the Roles subtab of the Security Console Administration tab. You can overwrite these values for the role that you're copying. However, any roles inherited by the copied role are unaffected by any name changes that you make on the Copy Role: Basic Information page.Click the Summary and Impact Report train stop.
Click Submit and Close, then OK to close the confirmation message.
Review the progress of your copy on the Role Copy Status subtab of the Security Console Administration tab. Once the status is Complete, you can edit the copied role.
If you prefer, you can visit the intermediate train stops after the Copy Role: Basic Information page and edit your copy of the role before you save it.
Editing Job and Abstract Roles
You can create a role by copying a predefined job role or abstract role and editing the copy.
On the Roles tab of the Security Console, search for and select your custom role.
In the search results, click the down arrow for the selected role and select Edit Role.
On the Edit Role: Basic Information page, you can edit the role name and description, but not the role code.
Click Next.
On the Edit Role: Functional Security Policies page, any function security privileges granted to the copied role appear on the Privileges tab. Select a privilege to view details of the code resources that it secures in the Details section of the page.
To remove a privilege from the role, select the privilege and click the Delete icon. To add a privilege to the role:
Click Add Function Security Policy.
In the Add Function Security Policy dialog box, search for and select a privilege or role.
If you select a role, then click Add Selected Privileges to add all function security privileges from the selected role to your custom role. If you select a single privilege, then click Add Privilege to Role.
Click OK to close the confirmation message.
Repeat from step 2 for additional privileges.
Close the Add Function Security Policy dialog box.
Click Next.
The Resources tab, which is read-only, lists any resources granted to the role directly rather than through function security privileges. As you can't grant resources directly to roles on the Security Console, only resource grants created before Release 12 could appear on this tab. You can't edit these values.
Make no changes on the Copy Role: Data Security Policies page.
Note: Whether this page is enabled for edit depends on the current setting of the Enable edit of data security policiesoption. Set this option on the Roles subtab of the Security Console Administration tab.
Click Next.
The Edit Role: Role Hierarchy page shows the copied role and its inherited aggregate privileges and duty roles. The hierarchy is in tabular format by default. You can add or remove roles.
To remove a role:
Select the role in the table.
Click the Delete icon.
Click OK to close the confirmation message.
To add a role:
Click the Add Role icon.
In the Add Role Membership dialog box, search for and select the role to add.
Click Add Role Membership.
Click OK to close the confirmation message.
Repeat from step 2 for additional roles.
Close the Add Role Membership dialog box.
The Edit Role: Role Hierarchy page shows the updated role hierarchy.
Click Next.
To provision the role to users, you must create a role mapping. Don't provision the role to users on the Security Console.
Click Next.
Copying and Editing Duty Roles
You can copy a duty role and edit the copy to create a duty role. Copying duty roles is the recommended way of creating duty roles.
On the Roles tab of the Security Console, search for the duty role to copy.
Select the role in the search results. The role hierarchy appears in tabular format by default.
Tip: Click the Show Graph icon to show the hierarchy in graphical format.
In the search results, click the down arrow for the selected role and select Copy Role.
In the Copy Options dialog box, select a copy option.
Click Copy Role.
On the Copy Role: Basic Information page, edit the Role Name, Role Code, and Description values, as appropriate.
Tip: The role name and code have the default prefix and suffix for copied roles specified on the Roles subtab of the Security Console Administration tab. You can overwrite these values for the role that you're copying. However, any roles inherited by the copied role are unaffected by any name changes that you make on the Copy Role: Basic Information page.
Click the Summary and Impact Report train stop.
Click Submit and Close, then OK to close the confirmation message.
Review the progress of your copy on the Role Copy Status subtab of the Security Console Administration tab. Once the status is Complete, you can edit the copied role
To edit the role:
On the Roles tab of the Security Console, search for and select your copy of the duty role.
In the search results, click the down arrow for the selected role and select Edit Role.
On the Edit Role: Basic Information page, you can edit the role name and description, but not the role code.
Click Next.
On the Edit Role: Functional Security Policies page, any function security privileges granted to the copied role appear on the Privileges tab. Select a privilege to view details of the code resources that it secures.
To remove a privilege from the role, select the privilege and click the Delete icon. To add a privilege to the role:
Click Add Function Security Policy.
In the Add Function Security Policy dialog box, search for and select a privilege or role.
If you select a role, then click Add Selected Privileges to grant all function security privileges from the selected role to your custom role. If you select a single privilege, then click Add Privilege to Role.
Click OK to close the confirmation message.
Repeat from step 2 for additional privileges.
Close the Add Functional Security Policies dialog box.
Click Next.
The Resources tab, which is read-only, lists any resources granted to the role directly rather than through function security privileges. As you can't grant resources directly to roles on the Security Console, only resource grants created before Release 12 could appear on this tab. You can't edit these values.
Make no changes on the Edit Role: Data Security Policies page.
Click Next.
The Edit Role: Role Hierarchy page shows the copied duty role and any duty roles and aggregate privileges that it inherits. The hierarchy is in tabular format by default. You can add or remove roles.
To remove a role:
Select the role in the table.
Click the Delete icon.
Click OK to close the information message.
To add a role:
Click Add Role.
In the Add Role Membership dialog box, search for and select the role to add.
Click Add Role Membership.
Click OK to close the confirmation message.
Repeat from step 2 for additional roles.
Close the Add Role Membership dialog box.
The Edit Role: Role Hierarchy page shows the updated role hierarchy.
Click Next.
On the Edit Role: Summary and Impact Report page, review the summary of changes. Click Back to make corrections. Otherwise:
Click Save and Close to save the role.
Click OK to close the confirmation message.
The role is available immediately.
Managing Data Security Policies
This topic provides an overview of data security and discusses concepts related to how you secure data by provisioning roles that provide the necessary access.
Comparing Function Security and Data Security
Function security is a statement of what actions you can perform in which user interface pages.
Data security is a statement of what action can be taken against which data.
Function security controls access to user interfaces and actions needed to perform the tasks of a job. For example, an accounts payable manager can view invoices. The Accounts Payable Manager role provisioned to the accounts payable manager authorizes access the functions required to view invoices.
Data security controls access to data. In this example, the accounts payable manager for the North American Commercial Operation can view invoices in the North American Business Unit. Since invoices are secured objects, and a data role template exists for limiting the Accounts Payable Manager role to the business unit for which the provisioned user is authorized, a data role inherits the job role to limit access to those invoices that are in the North American Business Unit. Objects not secured explicitly with a data role are secured implicitly by the data security policies of the job role.
Both function and data are secured through role-based access control.
Implementing Data Security
By default, users are denied access to all data.
Data security makes data available to users by the following means.
Policies that define grants available through provisioned roles
Policies defined in application code
You secure data by provisioning roles that provide the necessary access.
When you provision a job role to a user, the job role limits data access based on the data security policies of the inherited duty roles. When you provision a data role to a user, the data role limits the data access of the inherited job role to a dimension of data.
Data security consists of privileges conditionally granted to a role and used to control access to the data. A privilege is a single, real world action on a single business object. A data security policy is a grant of a set of privileges to a principal on an object or attribute group for a given condition. A grant authorizes a role, the grantee, to actions on a set of database resources. A database resource is an object, object instance, or object instance set. An entitlement is one or more allowable actions applied to a set of database resources.
Data security features include:
Data security policy: Defines the conditions in which access to data is granted to a role.
Role: Applies data security policies with conditions to users through role provisioning.
The sets of data that a user can access are defined by creating and provisioning roles. Oracle data security integrates with Oracle Platform Security Services (OPSS) to entitle users or roles (which are stored externally) with access to data. Users are granted access through the privilege assigned to the roles or role hierarchy with which the user is provisioned. Conditions are WHERE clauses that specify access within a particular dimension, such as by business unit to which the user is authorized.
Data Security Policies
Data security policies articulate the security requirement "Who can do what on which set of data."
For example, accounts payable managers can view AP disbursements for their business unit.
A data security policy is a statement in a natural language, such as English, that typically defines the grant by which a role secures business objects. The grant records the following.
Table or view
Entitlement (actions expressed by privileges)
Instance set (data identified by the condition)
For example, disbursement is a business object that an accounts payable manager can manage by payment function for any employee expenses in the payment process.
A data security policy identifies the entitlement (the actions that can be made on logical business objects or dashboards), the roles that can perform those actions, and the conditions that limit access. Conditions are readable WHERE clauses. The WHERE clause is defined in the data as an instance set and this is then referenced on a grant that also records the table name and required entitlement.
Working with Database Resources and Data Security Policies
A data security policy applies a condition and allowable actions to a database resource for a role. When that role is provisioned to a user, the user has access to data defined by the policy. In the case of the predefined security reference implementation, this role is always a duty role.
The database resource defines an instance of a data object. The data object is a table, view, or flexfield.
The following figure shows the database resource definition as the means by which a data security policy secures a data object. The database resource names the data object. The data security policy grants to a role access to that database resource based on the policy's action and condition.
A database resource specifies access to a table, view, or flexfield that is secured by a data security policy.
Name providing a means of identifying the database resource
Data object to which the database resource points
Actions correspond to privileges that entitle kinds of access to objects, such as view, edit, or delete. The actions allowed by a data security policy include all or a subset of the actions that exist for the database resource.
A condition is either a SQL predicate or an XML filter. A condition expresses the values in the data object by a search operator or a relationship in a tree hierarchy. A SQL predicate, unlike an XML filter, is entered in a text field in the data security user interface pages and supports more complex filtering than an XML filter, such as nesting of conditions or sub queries. An XML filter, unlike a SQL predicate, is assembled from choices in the UI pages as an AND statement.
Creating Custom Roles for Public Sector Community Development
This topic describes how to create custom roles required to enable design-time and runtime access for various features of Public Sector Community Development services. These custom roles are required for permits or planning and zoning services, and they are not delivered, predefined roles. They must be created manually.
In this task you need to create the following roles in the Security Console exactly as they appear in the following table.
Common Custom Roles
Role Code |
Role Name |
Description |
---|---|---|
CUSTOM_PSC_REGISTERED_PUBLIC_USER |
PSC Custom Registered Public User |
Custom role for grouping all the registered public user access for . While creating the CUSTOM_PSC_REGISTERED_PUBLIC_USER role, in the Role Hierarchy tab add as child roles the delivered role, PSC Registered Public User, and these custom roles. For Permits:
For Planning and Zoning:
|
Permits Service Custom Roles
Role Code |
Role Name |
Description |
---|---|---|
CUSTOM_PSC_MANAGE_PERMITS |
PSC Custom Manage Permits |
Allows users to apply for permits and update permits. |
CUSTOM_PSC_VIEW_PERMITS |
PSC Custom View Permits |
Allows users to view the permit detail tab in the permits application. |
CUSTOM_PSC_APPLY_PERMITS_DATA |
PSC Custom Permit Applicant Data Access |
Allows users to apply for permits and update their own permits in while in the status of pending. |
CUSTOM_PSC_MANAGE_PERMITS_AGENCY |
PSC Custom Permit Data Access for Agency |
Allows users to apply for permits and update permits that have not been closed. While creating the CUSTOM_PSC_MANAGE_PERMITS_AGENCY role, add the following roles as child roles on the Role Hierarchy tab:
|
Planning and Zoning Service Custom Roles
Role Code |
Role Name |
Description |
---|---|---|
CUSTOM_PSC_MANAGE_PNZ |
PSC Custom Manage Planning and Zoning Applications |
Allows users to apply for Planning and Zoning applications. |
CUSTOM_PSC_VIEW_PNZ |
PSC Custom View Planning and Zoning Applications |
Allows users to view Planning and Zoning applications. |
CUSTOM_PSC_APPLY_PNZ_DATA |
PSC Custom Planning and Zoning Applications Applicant Data Access |
Allows users to apply for Planning and Zoning applications and update their own Planning and Zoning applications in pending status. |
CUSTOM_PSC_MANAGE_PNZ_AGENCY |
PSC Custom Planning and Zoning Applications Data Access for Agency |
Allows users to apply for Planning and Zoning applications and update Planning and Zoning applications that are not closed. While creating the CUSTOM_PSC_MANAGE_PNZ_AGENCY role, add the following roles as child roles on the Role Hierarchy tab:
|
Creating Custom Roles for Public Sector Services
To create a role:
Navigate to the Security Console.
On the Roles tab of the Security Console, click Create Role.
On the Create Role: Basic Information page, enter the role's display name in the Role Name field.
This is the label for the role displayed in the interface when implementation teams set up security. Use the role name as listed in the previous tables. For example, enter PSC Custom Manage Permits or PSC Custom View Permits, depending on the role you are creating.
In the Role Code field enter the role code value of the role you are creating, exactly as it appears in the previous tables.
For example, enter CUSTOM_PSC_MANAGE_PERMITS.
In the Role Category field, select Financials - Job Roles.
Review the table above, and only for those roles that will contain child roles, click the Role Hierarchy tab, and add the child roles specified in the table above.
Save your changes.
When setting up security assignments for your user profiles, assign the roles to all of the appropriate users in the system to ensure the necessary access to permits.
See the following section for details.
For more information on using the Security Console, see Working with Roles in the Security Console.
For information on configuring security assignments for agency staff users, see Managing Agency Staff Profiles.
For information on configuring security assignments for public users, see Setting Up Public User Roles.
Assigning Roles
You assign roles to users in the system using delivered setup pages. For public users, you use the Public User Roles page and for agency staff members, you use the Agency Staff Access page.
User Type |
Role Assignments |
Setup Page |
---|---|---|
Anonymous User |
This is the default access available to all users, including users who have not signed in. You do not assign roles to this user type. |
None. |
Registered Public User |
CUSTOM_PSC_REGISTERED_PUBLIC_USER |
Public User Roles page |
System Administrator |
|
|
Business Analyst |
|
|
Branding Administrator |
|
Note: Typically, it is not recommended to assign PSC Registered Public User to any of the agency staff users, including the administrators. This user configuration should be used only for completing branding activities, such as updating themes and menu navigation. If the same user is required to perform any of the other related transactions or setup, then the PSC Registered Public User role should be removed from the user.
|
Permits agency staff members |
|
|
Planning and Zoning agency staff members |
|
|
Adding Roles to Agency Users for Creating Transaction Types
CUSTOM_PSC_MANAGE_PERMITS_AGENCY
CUSTOM_PSC_MANAGE_PNZ_AGENCY
ORA_CRM_EXTN_ROLE (This role will be available for assignment only after the first transaction type is created.)
ORA_FND_IT_SECURITY_MANAGER_JOB
ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB
Managing Custom Roles for Planning Application Access
This topic describes custom roles that need to be created for the Planning and Zoning service.
For information on the custom planning and zoning custom roles, see Creating Custom Roles for Public Sector Community Development.
Setting Up Users for the Oracle Inspector Mobile Application
System administrators set up Oracle Inspector with profiles and security before they can implement the application on their mobile devices.
Before an inspector or agency staff can install, configure, and use the Oracle Inspector mobile application, you must do the following:
Create an agency staff profile for each user.
Configure security for each user.
Provide the users with the correct base URL for production.
Creating an Agency Staff Profile
Make sure that each user has an agency staff profile to log into the mobile application. Because the application package configuration is secure, agency staff must enter their login credentials before the environment begins to download.
For more information about creating agency staff profiles, see the documentation for Managing Agency Staff Profiles.
Configuring Security
Agency administrators must explicitly grant mobile application access to the necessary agency user roles. Users can open the application but need the proper credentials. Make sure the appropriate users have one of the following roles assigned:
BUILDING_INSPECTOR
INSPECTOR_SUPERVISOR
For information about setting up roles, see the documentation for Managing Roles in Public Sector Compliance and Regulation.
Providing the Base URL for Production
Make sure you’re providing the users with the correct base URL for production. Implementation users need a test URL whereas agency staff must use the production URL in the field. See the instructions provided to inspectors and agency staff users about setting up the base URL in Installing and Configuring Oracle Inspector.
If needed, you can provide a new host URL, and users can reset the URL through the mobile application on the Reset Application URL page.