Alternatively, you can select any of these options from the Preset drop-down menu to specify default Solution Explorer security settings:

– Preset One – Preset Two – Preset Three

7

7

Using Security Workbench

This chapter contains the following topics:

■ Section 7.1, "Understanding Security Workbench"

■ Section 7.2, "Understanding Exclusive/Inclusive Row Security" ■ Section 7.3, "Creating Security Overrides"

■ Section 7.4, "Managing Application Security" ■ Section 7.5, "Managing Action Security" ■ Section 7.6, "Managing Row Security" ■ Section 7.7, "Managing Column Security"

■ Section 7.8, "Managing Processing Option and Data Selection Security" ■ Section 7.9, "Managing Tab Security"

■ Section 7.10, "Managing Hyper Exit Security"

■ Section 7.11, "Managing Exclusive Application Security" ■ Section 7.12, "Managing External Calls Security"

■ Section 7.13, "Managing Miscellaneous Security"

■ Section 7.14, "Managing Push Button, Link, and Image Security" ■ Section 7.15, "Managing Text Block Control and Chart Control Security" ■ Section 7.16, "Managing Media Object Security"

■ Section 7.17, "Managing Application Query Security" ■ Section 7.18, "Managing Data Browser Security"

■ Section 7.19, "Managing Published Business Services Security" ■ Section 7.20, "Copying Security for a User or a Role"

■ Section 7.21, "Reviewing and Deleting Security Records on the Work With

User/Role Security Form"

■ Section 7.22, "Running Security Workbench Records Reports"

7.1 Understanding Security Workbench

Use Security Workbench to apply security to JD Edwards EnterpriseOne applications, application versions, forms, and other objects within JD Edwards EnterpriseOne that

*PUBLIC. JD Edwards EnterpriseOne stores security information in the F00950 table and caches the security information in the web server's memory for the web clients and each workstation's memory on Microsoft Windows clients. For Microsoft Windows client users, changes made to security are applied after the user exits JD Edwards EnterpriseOne and signs back in. For the security changes to take affect on web clients, you must restart the web server or clear the web server's cache using the Server Administration Workbench (SAW) application.

When applying object level security, you need to consider how JD Edwards EnterpriseOne checks for security. When a user signs in, the system first checks the user ID for security. If no object security is assigned to the user ID, then it checks the role (if the user is part of a specific role), and then finally it checks *PUBLIC.

7.2 Understanding Exclusive/Inclusive Row Security

You use row security to either restrict or allow users from viewing, updating, deleting, or adding certain records (rows) to a table. Prior to setting up any kind of row security (whether at the user level, role level, or *PUBLIC level), security administration determines whether your system will use inclusive or exclusive row security.

Exclusive row security blocks users from accessing the database for a secured range of values that you define. Inclusive row security allows users to access the database for a valid range of values that you define. You use the EnterpriseOne Security program (P98OWSEC) to set up user security.

You use the Row Security application in the Security Workbench program (P00950) to define database values to be excluded or included depending on your JD Edwards EnterpriseOne security configuration. You can set up row security for a user, role, and *PUBLIC. Exclusive row security and inclusive row security are mutually exclusive; you cannot use a combination of the two.

To illustrate exclusive and inclusive row security, assume that user MG5700778 should be able to view records in the Address Book table (F0101) that have a business unit value from 1 through 20 and from 51 through 70. In addition, this user should be able to update records in the Address Book table that have a business unit value from 1 through 20. This user cannot insert or delete any records in the Address Book table. The following examples show the records you must define and the SQL statements that the system performs for both exclusive and inclusive row security.

7.2.1 Exclusive Row Security

This table shows the records that you define using the Row application in Security Workbench when you use exclusive row security to secure your system:

Note: You can access Security Workbench on the JD Edwards EnterpriseOne web client, as well as the Microsoft Windows client.

User

Tabl

e Data item

From

Value Thru Value Add Change Delete View Alias

MG5700778 *ALL CostCenter 1 20 N Y N Y MCU

MG5700778 *ALL CostCenter 21 50 N N N N MCU

MG5700778 *ALL CostCenter 51 70 N N N Y MCU

This example shows the Select operation that the system performs against the F0101 table:

SELECT * FROM TESTDTA.F0101 WHERE ( ABMCU NOT BETWEEN ' 21' AND ' 50' AND ABMCU NOT BETWEEN ' 71' AND ' ZZZZZZZZ' ) ORDER BY ABAN8 ASC

This example shows the Update operation that the system performs against the F0101 table:

UPDATE TESTDTA.F0101 SET

ABALKY='MG5700778',ABTAX='456456456',ABALPH='John

Doe',ABDC='JOHNDOE',ABMCU=' 1',ABSIC=' ',ABLNGP=' ',ABAT1='E',ABCM=' ',ABTAXC=' WHERE ( ABAN8 = 9999999.000000 ) AND ( ABMCU NOT BETWEEN ' 21' AND ' 50' AND ABMCU NOT BETWEEN ' 51' AND ' 70' AND ABMCU NOT BETWEEN ' 71' AND ' ZZZZZZZZ' )

7.2.2 Inclusive Row Security

This table shows the records that you define using the Row application in Security Workbench when you use inclusive row security to secure your system:

This example shows the Select operation that the system performs against the F0101 table:

SELECT * FROM TESTDTA.F0101 WHERE ( ( ABMCU BETWEEN ' 1' AND ' 20' OR ABMCU BETWEEN ' 51' AND ' 70' ) ) ORDER BY ABAN8 ASC

This example shows the Update operation that the system performs against the F01010 table:

UPDATE TESTDTA.F0101 SET ABALKY=' ',ABTAX='546',ABALPH='John Doe',ABDC='JOHNDOE',ABMCU=' 60',ABSIC='

',ABUSER='MG5700778',ABPID='EP01012',ABUPMJ=101214,ABJOBN='DEN123456', ABUPMT=154030.000000 WHERE ( ABAN8 = 6864221.000000 ) AND ( ABMCU BETWEEN ' 1' AND ' 20' )

Note: Row security is applied for the range of values that have N in the appropriate Add/Change/Delete/View action.

User Table Data Item

From Value

Thru

Value Add Change Delete View Alias

MG5700778 F0101 CostCenter 1 20 N Y N Y MCU

MG5700778 F0101 CostCenter 51 70 N N N Y MCU

Important: The presence of a single record or a set of security records in the Security Workbench table (F00950) with all N values for one or more operations for a table and data dictionary combination will disallow that user from performing that particular operation on the table.

Note: Row Security is applied for range of values that have Y in the Add/Change/Delete/View action

As illustrated in the examples, when you define data access security using exclusive row security, you identify a range of values that are to be secured from the user. When you define data access security using inclusive row security, you identify a range of values that the user can access. Depending on your security setup, inclusive row security can increase performance over exclusive row security. The reason for the performance increase is due to the select and update statements that the middleware generates. Performance can be improved if the use of inclusive row security results in a small range of valid values in the row security application rather than specifying a large range of secured values in the row security application to use exclusive row security.

7.2.2.1 Activating Inclusive Row Security

The system assumes Exclusive Row Security unless you specify inclusive row security. Use these steps to activate inclusive row security: