Setting Up Commitment Control Security

This chapter provides an overview of setting up security for Commitment Control and describes how to:

• Set up Commitment Control security fields.

• Set up Commitment Control security events.

• Set up Commitment Control security rules.

• Assign Commitment Control security rules to user IDs, permission lists, and dynamic views.

• Run the Commitment Control Security process (KSEC_FLAT) and Commitment Control Security report, GLC8572 (Crystal) or GLX8572 (XMLP).

• Set up PS/nVision reporting security.

Understanding Commitment Control Security

Commitment Control security augments the security used by your PeopleSoft Enterprise applications, enabling you to secure the Commitment Control functions, such as creating or modifying budgets or overriding exceptions, that a user may perform on ChartField combinations for which you have established control budgets.

To set up Commitment Control security, you define a series of security rules that enable particular Commitment Control functions for particular budgets. You then apply those security rules to user IDs, permission lists, or dynamic views consisting of user IDs and associated ChartFields.

This section discusses:

• Security set up order.

• Security events.

• Security rules.

• Security rule assignment.

Security Set Up Order

Use the following order for setting up security for Commitment Control:

1. Enable standard PeopleSoft application security.

   Define users, roles, and permission lists.

   Note. Coordination of overall system security options and commitment control security is important. For example, if you select options on the Security Options page by user ID, and if you select only the Business Unit check box and not the Ledger check box, the user is not able to select any ledger group for budget journals. Instead the system returns the message "No matching values were found" and the user cannot select ledger groups.
   
   In other words, when the Security Options page has User ID Level Security selected, for any user who wants to access Ledger Group, the Ledger check box for Secured Fields must be selected and Ledger by User ID must be appropriately set up.

2. Security field setup comes predefined.

   We recommend that you not edit any of the fields on this page unless you are configuring (making changes, such as adding deleting, activating, inactivating, or renaming) Commitment Control ChartFields.

   If you are configuring ChartFields, define the ChartFields that you want to secure on the Security Field Setup page. You can establish security for any ChartField that you define as a key ChartField in the control budget definition, as well as Budget Period, Ledger Group, and Ledger.

3. Select the events that you want to secure on the Security Events page.

   Commitment Control predefines the seven events that can trigger security: Budget Entry or Adjustment, Budget Transfers, Bypass Budget, Budget Override, Budget Date Override, Workflow Notification, and Budget Inquiry.

   The default security setting for these events is inactive.

   Note. It is useful to know which events you want to secure before you proceed with security setup; however, it might be helpful to defer activating security events until just before running the security build process. The security build process builds the security records only for events that are activated. Deferring activation enables you to verify that the security rules you are building correctly enforce the security events, and it ensures that you are not hampered by security being activated during setup or until you are ready for security to be applied.

4. Define security rules for these events in the Rule Definitions component.

   Security rules apply event security to the ChartField combinations (budgets) that you want to secure.

5. Assign security rules to individual user IDs and permission lists to tell the system which events a user has the authority to conduct for specific budgets.

   You can also apply security rules dynamically, using a predefined record that contains the user IDs and the ChartField or ChartFields defined in a dynamic rule group. Use the Associate Rules to User ID, Assoc Rules to Permission List, or Attach Dynamic Rules pages.

6. Run the Commitment Control Security (KSEC_FLAT) process , also known as the security flattening process, from the Request Build page.

   This process uses security rules and assignments to populate the tables that the system uses to check security authority during transaction entry. This Application Engine process must be run before security rules and assignments become effective.

7. You can Run the Commitment Control Security report, GLC8572 (Crystal) or GLX8572 (XMLP), to view the results of the Commitment Control Security process.

The system uses these security settings to enforce security for Commitment Control across all applications in your installation. Any event that requires security processing initiates a call to the security function on a predetermined trigger, such as entering or saving a page. The system does not process any events that fail the security rule for the user ID.

See Also

Key ChartFields and Translation Trees

Securing Your System

Enterprise PeopleTools 8.5x PeopleBook: PeopleSoft Security

Security Events

Commitment Control uses security events to enable you to specify the budgetary functions, or events, on which the system enforces security. There are seven event types for which you can enable security:

• Budget Entry or Adjustment

• Budget Transfer

• Budget Override

• Budget Date Override

• Bypass Budget

• Workflow Notification

• Budget Inquire

You enable security separately for each event on the Security Events page. This enables you to decide whether to implement security across all control-budgeting functions (events) or a limited set of functions. For example, you may want to enable security for budget journal entry and adjustments to limit this activity to a small set of users, but not enable security for inquiring on existing budgets so that all users can check on the status of a budgeted amount.

The following table shows how each security event restricts access to Commitment Control functions when you activate it. The table also provides links to detailed discussions of the functions themselves:

Security Rules

Security rules enable you to establish which security events can be performed on which budgets and which transactions independent of any specific user until such time as you apply the rules to a user or users. For example, you can create one security rule to enable budget entry, transfers, notification, and inquiry for a budget (or group of budgets) and create a different security rule that enables only inquiry for the same budget (or budget group). After you define your security rules, you can assign these rules to a specific user ID or all the users and roles assigned to a permission list. You can also use a dynamic rule group, which uses a SQL view that joins user IDs with ChartField values to dynamically assign users access to budgets with particular ChartField values.

The following rules govern how Commitment Control applies security rules to user IDs and permission lists:

• For events that do not require a super user rule, you can create security rules that allow access to the budgets you specify for the security events you specify.

  You can also create security rules that disallow such access.

  Note. A super user rule is required to perform budget override, date override, and bypass at the transaction level.

  When you assign a user to a security rule that allows access, the system denies the user access to any budgets and active security events that are not specified in that security rule, unless that user is assigned to another security rule that does allow access to budgets and security events not specified in the first security rule.

  When you assign a user to a security rule that disallows access, the system denies the user access to the budgets and active security events you specify and gives the user access to all other budgets for those security events, unless that user is assigned to another security rule that disallows access to those unspecified budgets.

  The choice between allow and disallow can save you time and effort when defining security rules. When you want to allow access to only a few budgets, use the allow attribute to specify them. When you want to allow access to all but a handful of budgets, use the disallow attribute to specify those that you want to deny access to instead of entering rows and rows of allowed budgets.

  Note. All users automatically have access to inactive security events for all budgets, regardless of the security rules you establish.

• You can create security rules defined solely for super users.

• You can assign multiple security rules to a single user—that is, a user may have one set of security rights for one group of budgets and a different set of security rights for another group of budgets.

  If you grant a user multiple security rules, and the security rules provide conflicting security access, the security rules that disallow access take precedence.

• You must set up and assign security rules for users to provide access to any security event that is active.

  If no security rules for a particular security event are assigned to a user, then that user has no access to that security event for any budget.

The following example provides a simplified illustration of how you can use security rules to limit a user's access to a specific set of events for a set of budgets.

Table 1: Associating Security Rules with Security Events:

Table 2: Associating User IDs with Security Rules:

User Tammy Jones is associated with security rules A and B. According to security rule A, Ms. Jones has the security to perform the following events on budget #1: entering and adjusting, inquiring, and receiving notifications about exceptions. Security rule B enables her to inquire on and be notified of exceptions for budget #2.

User Roger Smith, also associated with security rule B, can be notified whenever an exception for budget #2 occurs and can inquire on budgetary information. However, unlike Tammy Jones, Mr. Smith cannot perform any events for budget #1.

User Harry Brown is a Junior Financial Analyst in the corporate group. Security rule C lets him inquire on the budgetary information for all budgets, but he cannot perform any substantive actions on these budgets.

Grouping Budgets for Security

You can define security rules for specific budgets and for a range or group of budgets. Instead of specifying each individual ChartField combination that you want to include within a security rule, you can specify ranges of budgets by entering ranges of ChartField values.

There are three parameters you can use to enter ranges of ChartFields:

• Range: Enter the first and last ChartField value in a range.

  If you enter account 10000 as the start value and 20000 as the end value, for example, you include all budgets with accounts 10000 through 20000 that meet the other ChartField value criteria in the ChartField combination.

• Wild Card: Enter a wildcard (%).

  For example, if you enter department 14%, you include all budgets with departments beginning with 14 that meet the other ChartField value criteria in the ChartField combination. If you enter % alone, you include budgets for all departments that meet the other ChartField value criteria in the ChartField combination.

• Tree: Enter a translation tree and node to include budgets for that node and all the ChartField values that are children of that node (and which meet the other ChartField value criteria in the ChartField combination).

  Usually you can use the key ChartField translation trees you set up for control budget definitions.

  Note. You use Explicit when you want to select a single ChartField value, which you enter in the Start field.

  See Key ChartFields and Translation Trees.

  Here is an example of how you can use grouping parameters to define a group of budgets for a security rule. Assume that you entered the following ChartField values in a security rule:

ChartField Combination Set#1:

ChartField Combination Set#2:

The following is an excerpt from the BUD_ACCOUNT ChartField tree for this example:

Accounts ChartField tree excerpt

Assume that the following budgets are defined:

Your security rule would apply to the budgets whose ChartField values appear in italics in the table.

Conflicting Security Rules

If a budget action, or event, by a user passes any one rule, it passes the security check completely. The exception to this is when there are one or more rules that conflict. In a conflicting rules situation, the default is to disallow and the action fails security.

For example, if rule 1 is allow budget entry for DeptID 10000 through 20000 and rule 2 is to Disallow budget entry for DeptID 12000 through 21000 and both rules are assigned to the same user there is a conflict. Any attempt by that user to do a budget entry for DeptID 12000 through 20000 fails Commitment Control security.

Dynamic Security Rules

You use dynamic rules to assign security events to a ChartField that you define as a bind variable rather than a particular value or range of values. The bind variable is resolved by a view, called the dynamic rule record, that associates a user ID with a ChartField value.

See the discussion of Attaching Rules to Dynamic Rule Groups in the following section, Security Rule Assignment.

Security Rule Assignment

Once you have defined your security rules and applied those rules to events and business units, you are ready to attach the rules to users. You have the option to attach rules to single user IDs, to permission lists, or to dynamic rule groups.

Attaching Rules to User IDs

Assigning security rules to user IDs enables you to attach specific security rules to individuals. This can be tedious and can require a lot of maintenance for a large number of users, but it does provide a useful method for attaching special rules (such as a super user rule) to select users.

Attaching Rules to Permission Lists

Often you need to assign the same budget security to all the users of a permission list. While you could assign the security rule to each individual user, this would produce a maintenance issue in that if you needed to add a new security rule, you would have to add this rule multiple times. By taking advantage of the permission lists set up as part of your standard PeopleSoft application security, you can attach rules to a permission list, which then enables these rules for all users associated with the permission list.

Attaching Rules to Dynamic Rule Groups

In cases where a user is associated with a particular ChartField value, such as a manager and a department ID, you can create dynamic security rules and dynamic rule groups. Dynamic rule groups use a SQL view that you must define yourself, called the dynamic rule record, that joins the user ID and the ChartField value. Each user in the dynamic rule group has access to the budgets that include the ChartFields that the user is associated with in the dynamic rule record, for the security events defined in the dynamic security rule. This is far more convenient than creating and maintaining separate rules and attaching them individually to each user.

To set up dynamic rule groups, do the following:

1. Define a dynamic security rule in the Rule Definitions component.

   This rule assigns a bind variable to the ChartField that is resolved by the dynamic rule record.

2. Use Application Designer to define a dynamic rule record, a SQL view that includes the user ID field and the ChartField that uses the parameter Bind in the dynamic rule.

   For an example of a dynamic rule record, see the delivered record KK_DYN1 by opening the record in the PeopleSoft Application Designer.

3. Define a dynamic rule group by attaching the dynamic security rule to the dynamic rule record on the Attach Dynamic Rules page.

The Commitment Control Security (KK_SEC_FLAT) process creates security rows using the user ID and ChartField values from the dynamic rule record rows.

Dynamic Rule Group Example

Assume that you want to allow department managers to inquire only on their own departmental budgets. Do the following:

1. Define a dynamic security rule with department ID (DEPTID) defined as a bind variable and apply it to the Budget Inquire security event.

2. Define a dynamic rule record with the fields user ID (OPRID) and department ID, based on a join of the DEPT_TBL, the PERSONAL _DATA table, and the OPRALIAS table:

   SELECT a.deptid 
                   
   , C.OPRID 
                   
   FROM PS_DEPT_TBL A 
                   
   , PS_PERSONAL_DATA B 
                   
   , PSOPRALIAS C 
                   
   WHERE A.MANAGER_NAME = B.NAME 
                   
   AND B.EMPLID = C.EMPLID

3. Define a dynamic rule group by attaching the dynamic security rule to the dynamic rule record.

4. Run the Commitment Control Security process.

See Also

Assigning Commitment Control Security Rules

Setting Up Commitment Control Security Fields

To set up commitment control security fields, use the Field Setup (KSEC_CHARTFIELD) component.

This section discusses how to enable ChartFields for Commitment Control security.

See Also

Security Set Up Order

Page Used to Define Security Fields

Defining Security Fields

Access the Commitment Control Security Field Setup page (Commitment Control, Define Budget Security, Field Setup, Commitment Control Security Field Setup).

Warning! Do not edit the delivered security fields unless you are configuring your Commitment Control ChartFields.

Setting Up Commitment Control Security Events

To set up commitment control security events, use the Events (KSEC_EVENT_ENTRY) component.

This section discusses how to activate security for specific Commitment Control functions, known as security events.

See Also

Security Events

Page Used to Activate Security Events

Activating Security Events

Access the Commitment Control Security Events page (Commitment Control, Define Budget Security, Events, Commitment Control Security Events).

Select the check box for any of the seven security events (Commitment Control functions) to which you want to restrict access or add constraints to the use of the events.

Setting Up Commitment Control Security Rules

To set up commitment control security rules, use the Security Rule Definition (KSEC_RULE_ENTRY) component.

Security rules enable you to establish, independently of any specific user, which security events can be performed on which budgets. Setup for security rules consists of two steps, described in this section:

1. Defining the security rules and applying them to business units.

2. Applying the security rules to security events.

See Also

Security Set Up Order

Pages Used to Define Security Rules

Defining Security Rules

Access the Rule Definition page (Commitment Control, Define Budget Security, Rule Definitions, Rule Definition).

Attribute

Select one of the following: Allow: Create a security rule that allows users access to the ChartField combinations that you specify in the Security Rule Combination scroll area, for the business units you specify in the Apply Rule to Business Units scroll area, and the security events that you specify on the Apply Rule page. Users are denied access to any ChartField combinations, security events, and business units that you do not specify, unless they have access through another security rule. Disallow: Create a security rule that prevents a user from accessing the ChartField combinations that you specify in the Security Rule Combination scroll area for the business units you specify in the Valid Business Units scroll area and the security events that you specify on the Apply Rule page. Users are granted access to any ChartField combinations that you do not specify for the security events and business units that you do specify. Super User: Create a super user security rule. When you select Super User, the system automatically makes the Security Rule Combination scroll area unavailable. Users attached to a super user rule have access to all budgets and business units for the event or events you specify on the Apply Rule page. Of the following security events, the only event that makes a distinction between transaction level and budget level is the Budget Override event. The other two must be associated with a Super User rule: Budget Date Override Bypass Budget Budget Override

Security Rule Combination

Budget ChartField Values and Budget ChartField Tree Values

Apply Rule to Business Units

Apply the rule either to all valid business units or to the business units you specify in the grid.

Applying Security Rules to Security Events

Access the Apply Rule page (Commitment Control, Define Budget Security, Rule Definitions, Apply Rule).

Apply Rule to Security Events

See Security Events.

Applicable Modules for Budget Date Event

Available only when you select the BUDG_DT (budget date override) Security Event.

Applicable Source Transactions for Override Event

Available only when you select the OVERRIDE (budget override) Security Event.

Note. Selecting Do not Allow Override as the Override Budget Checking option for a source transaction type on the Source Transactions - Options page is only effective if the override event is inactive within commitment control security.

Assigning Commitment Control Security Rules

To assign commitment control security rules, use the following components:

• Attach Rules to User ID (KSEC_OPR_RULES).

• Attach Rules to Permission List (KSEC_CLSS_RULES).

• Attach Dynamic Rules (KSEC_DYN_RULES).

Once you have defined your security rules, you must assign them to users. This section discusses how to:

• Assign security rules to a user ID.

• Assign security rules to a permission list.

• Assign dynamic rules to dynamic rule groups.

See Also

Security Rule Assignment

Setting Up Commitment Control Security Rules

Pages Used to Assign Commitment Control Security Rules

Attaching Rules to User IDs

Access the Assign Commitment Control Security Rule to User ID page (Commitment Control, Define Budget Security, Assign Rule to User ID, Assign Commitment Control Security Rule to User ID).

Select the security rules you want to assign to the user ID. You can assign only Regular rule types to user IDs. If the security rules you assign have conflicting Allow/Disallow attributes, the Disallow attribute takes precedence. For example, if security rule A allows inquiries on budgets with account 10000 and security rule B disallows inquiries on account 10000, security rule B takes precedence for account 10000.

Attaching Rules to Permission List

Access the Assign Commitment Control Security Rule to Permission List page (Commitment Control, Define Budget Security, Assign Rule to Permission List, Assign Commitment Control Security Rule to Permission List).

The same factors that apply to attaching rules to user IDs apply when you attach rules to permission lists.

Attaching Dynamic Rules

To attach dynamic security rules to a dynamic group:

1. Define a dynamic rule record for the security rule.

2. In Application Designer, create a view that includes:

   1. User ID (OPRID).

   2. The ChartField that uses the parameter bind in the dynamic security rule.

      For an example, see the delivered sample dynamic record KK_DYN1, which includes department ID and user ID. This view was created with the following SQL:

      SELECT a.deptid 
                      
      , C.OPRID 
                      
      FROM PS_DEPT_TBL A 
                      
      , PS_PERSONAL_DATA B 
                      
      , PSOPRALIAS C 
                      
      WHERE A.MANAGER_NAME = B.NAME 
                      
      AND B.EMPLID = C.EMPLID

3. Access the Assign Commitment Control Security Rule to Dynamic Group page (Commitment Control, Define Budget Security, Assign Rule to Dynamic Group, Assign Commitment Control Security Rule to Dynamic Group) by entering a dynamic rule group ID and the dynamic rule record.

4. Select the security rules you want to assign to the user ID.

   You can assign only Dynamic rule types to dynamic rule groups, and only dynamic rules that define the ChartField on the dynamic rule record as a bind variable. If the security rules you assign have conflicting Allow/Disallow attributes, the Disallow attribute takes precedence. For example, if security rule A allows inquiries on budgets with account 10000 and security rule B disallows inquiries on account 10000, security rule B takes precedence for account 10000.

See Also

Defining Security Rules

Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer

Running the Commitment Control Security Application Engine Process (KSEC_FLAT) and the Commitment Control Security Report (GLC8572 or GLX8572)

Before your security rules and assignments can take affect, you must run the Commitment Control Security Application Engine (KSEC_FLAT) process to create the tables used by the system to check security access. You can view the results of the process on the Commitment Control Security (GLC8572 or GLX8572) report.

Pages Used to Run the Commitment Control Security Process

See Also

Setting Up Commitment Control Security Rules

Setting Up PS/nVision Reporting Security

Use the commitment control ledger template (COMMITMENT) to provide the option to access a secured reporting view for restricted commitment control ledger access for PS/nVision reports as discussed in the PeopleTools security documentation.

Specify the ledger reporting view LED_RPTG_KK_VW in the Secured Rptg Vw (secured reporting view) field to secure access to commitment control ledgers by authorized user IDs during PS/nVision reporting. Because this is an optional security field, if you do not specify a ledger reporting view, PS/nVision provides reporting directly against the ledger.

Page Used to Set Up PS/nVision Reporting Security

See Also

Enterprise PeopleTools PeopleBook: PS/nVision, Setting Up PS⿄nVision Security, Implementing PS/nVision Ledger-Based Data Security

Granting nVision Reporting Access