2 Understanding JD Edwards EnterpriseOne Security

This chapter contains the following topics:

2.1 JD Edwards EnterpriseOne Security Overview

JD Edwards EnterpriseOne security enables a security administrator to control security for individual users and for groups of users. Setting up security correctly ensures that users in the system have permission to perform only those actions that are essential to the completion of their jobs. The User Security application (P98OWSEC) uses the F98OWSEC table to manage the JD Edwards EnterpriseOne user IDs and system (database) user IDs. Use P98OWSEC to create, test, and change user security for JD Edwards EnterpriseOne and the logically attached database management systems.

See Setting Up User Security.

The Security Workbench application (P00950) enables you to secure JD Edwards EnterpriseOne objects, such as applications, forms, rows, tabs, and so on. It stores all objects security records in the F00950 table.

See Using Security Workbench.

2.2 Object-Level Security

JD Edwards EnterpriseOne security is at the object level. This level means that you can secure specific objects within JD Edwards EnterpriseOne, which provides flexibility and integrity for your security. For example, you can secure a user from a specific form and then, no matter how the user tries to access the form (using a menu or any application that calls that form), the software prevents access to the form. The software simplifies the process of setting up security by enabling you to set security for hundreds of objects at one time by securing all objects on a specific menu or by securing all objects under a specific system code.

Note:

Only the objects are secured; the software does not support menu or system code security. Object security provides a higher level of integrity.

For example, if you secured a specific menu to prevent users from accessing the applications on that menu, the users might still be able to access those applications through another menu or another application that accesses the applications that you wanted to secure.

2.2.1 Object Level Security Types

At specific object levels, you can set these levels of security, alone or in any combination, for users and groups:

Level of Security Description
Application security Secures users from running or installing, or both, a particular application, an application version, or a form within an application or application version. You cannot define Application security at the subform level.
Action security Secures users from performing a particular action, such as adding, deleting, revising, inquiring, or copying a record. You define Action security at the application, version, and form level. You cannot define Action security at the subform level.
Row security Secures users from accessing a particular range or list of records in any table.

For example, if you secure a user from accessing data about business units 1 through 10, the user cannot view the records that pertain to those business units.

Column security Secures users from viewing a particular field or changing a value for a particular field in an application or application version. This item can be a database or non-database field that is defined in the data dictionary, such as the work/calculated fields.

For example, if you secure a user from viewing the Salary field on the Employee Master application, the Salary field does not appear on the form when the user accesses that application.

Processing option security Secures users from viewing or changing the values of processing options, or from prompting for versions and prompting for values for specific applications or application versions.

For example, if you secure a user from changing the processing options for Address Book Revisions, the user could still view the processing options (if you did not secure the user from prompting for values), but would not be able to change any of the values.

If you secure a user from prompting for versions, the user would not be able to see the versions for a specific application, so the user would not be able to select a different version of an application from the version that the administrator assigned.

Tab security Secures users from viewing or changing fields in a tab or tabs on a given form. You define Tab security at the application, version, and form level. You cannot define Tab security at the subform level.
Exit security Secures users from menu bar exits on JD Edwards EnterpriseOne forms. These exits call applications and allow users to manipulate data. Exit security also restricts use of the same menu options.
Exclusive application security Overrides row security that is set for an application. When you set exclusive application security for a user, the system overrides row security for every table that is accessed by the application that is specified. All other security still applies.
External calls security Secures users from accessing standalone executables that exist external to JD Edwards EnterpriseOne. These external executables, which might include design tools, system monitors, and debugging tools, are specific to JD Edwards EnterpriseOne.
Data Browser security Controls access to the Data Browser program.
Published business service security Controls access to published business services. For published business services, JD Edwards EnterpriseOne uses a "secure by default" security model which means that users cannot access a published business service unless a security record exists that authorizes access. For all other objects in JD Edwards EnterpriseOne, access is granted unless otherwise secured or restricted.
Push button, image, and link security Controls whether users can user or view push button, link, and image controls.
Media object security Controls whether users can add, change, delete, or view media objects within interactive applications, forms, or application versions.

2.3 Users, Roles, and *PUBLIC

The JD Edwards EnterpriseOne security administrator can set up security for:

  • A particular user

    This option controls security by specific JD Edwards EnterpriseOne user ID.

  • A user role

    This option controls security by role, which enables you to group users based on similar job requirements. An example is putting all of the accounts payable clerks in one role, such as Accounts Payable (AP).

  • All users

    This option controls security for all users who are designated by ID type *PUBLIC in the User or Role field. The designation *PUBLIC is a special ID within JD Edwards EnterpriseOne that automatically includes all of the users within it. You can use this ID to apply security even if you do not have a specific record set up for it in user profiles.

2.4 How JD Edwards EnterpriseOne Checks Security

When a user attempts to access an application or perform an action, JD Edwards EnterpriseOne checks security for that particular user ID. If security exists for that user ID, the software displays a message indicating that the user cannot proceed.

If the user ID has no security, the software checks role profiles (if that user is part of a specific role), and then *PUBLIC for security. If no security is established at any of these levels, the software allows the user to continue.

JD Edwards EnterpriseOne also provides software license security through protection codes, and it requires user validation at sign-in and when accessing new data sources.

2.5 Cached Security Information

When changes to security are made using the Security Workbench application (P00950), the changes are not immediately recognized in any environment because the records in the system data source are cached. For security changes to be enabled, the cache must be cleared.

2.5.1 Clearing the Cache on a Workstation Client

If system administrators make changes to the P00950 table, the changes are not immediately realized on workstations that are logged on to the system while security revisions are being made. To enable security changes, you clear the workstation's memory cache by signing off and signing back on to the workstation.

2.5.2 Clearing the Cache on a Web Client Using Server Manager

To clear the cache on a web client for JD Edwards EnterpriseOne Tools Release 8.97 and later releases, you use Server Manager. Use these steps to clear the cache using Server Manager:

  1. Access the Server Manager Management Console:

    http://server_name:port/manage

  2. Select the JAS Server instance for which you want to clear the cache from the Instance drop-down list box.

  3. Select JDBj database caches from the Runtime Metrics section in the left pane.

  4. Select the check boxes for the caches to be cleared.

  5. Click Clear Cache.

    The following caches are available to be cleared:

    • Data Dictionary Glossary Text

    • Data Dictionary Alpha Cache

    • Row Column Cache

    • JDBJ Security Cache

    • JDBJ Service Cache

    • Serialized Objects

    • Menu Cache

2.5.3 Clearing the Cache on a Web Client

To clear the cache on a web client for JD Edwards EnterpriseOne Tools Release 8.96 and earlier releases, you can use any of the these three methods:

2.5.3.1 Method One

Stop and then start the JD Edwards EnterpriseOne instance on the JAS Server.

2.5.3.2 Method Two

For JD Edwards EnterpriseOne releases 8.9 and later, open the Web Server Administration Workbench (SAW) and clear the JAS cache. To access SAW for JAS, you add /saw to the end of the URL, for example:

http://<web server>:<port>/jde/saw

Use these steps to clear the security cache on the selected JAS server:

  1. Sign on to the SAW JAS tool.

  2. Select Work with JDBJ from the header section under the Views option.

  3. Select Security Cache from the Data Refreshing field in the upper right-hand corner of the pane.

  4. Click the Click Here to Continue button that is in the bottom pane.

The security cache on the selected JAS server is cleared.

2.5.3.3 Method 3

You can set the security cache to clear itself without stopping and starting the server or using SAW to manually clear the cache. To automatically clear the security cache at specified intervals, you configure the securityCachePurge setting in the JDBj.ini file, as illustrated here:

[JDBj-RUNTIME PROPERTIES]

securityCachePurge=xxxxx (where xxxxx is a number in milliseconds.)