18 Understanding Authorization Security

This chapter contains the following topics:

• Section 18.1, "JD Edwards EnterpriseOne Authorization Model"

• Section 18.2, "Users, Roles, and *PUBLIC"

• Section 18.3, "Object-Level Security"

• Section 18.4, "Authorization Security for Business Units"

• Section 18.5, "Authorization Security for User Defined Objects"

• Section 18.6, "Cached Security Information"

18.1 JD Edwards EnterpriseOne Authorization Model

JD Edwards EnterpriseOne authorization 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 JD Edwards EnterpriseOne authorization security model is not secured by default. You should explicitly lock down all users by setting up different types of EnterpriseOne security for *PUBLIC, and then set up inclusive security to grant rights to roles.

EnterpriseOne applies authorization security in the following sequence for the signed-in user:

When a user attempts to access an application or perform an action, 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.

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

18.2 Users, Roles, and *PUBLIC

The EnterpriseOne security administrator can set up security for:

• A particular user

  This option controls security by specific 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 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.

18.3 Object-Level Security

EnterpriseOne authorization security is at the object level. This level means that you can secure specific objects within 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.

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

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.

18.3.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 of users assigned to a particular role:

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. Application security also applies to EnterpriseOne mobile applications.

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.

Hyper 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.

Solution Explorer security

Secures users from performing and viewing certain features within Solution Explorer, such as Menu Filtering and Fast Path.

Miscellaneous security

Provides additional security options to prevent users from running reports that update EnterpriseOne database tables. You can also use Miscellaneous security to configure different levels of access to workflows.

Data Browser security

Controls access to the Data Browser application.

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.

Text Block and Chart Control security

Controls whether users can use or only view text block and chart controls.

Application Query security

Prevents users from performing searches if they have not entered search criteria in the form filter fields or QBE fields.

Published business service security

Controls access to published business services. For published business services, 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.

18.4 Authorization Security for Business Units

EnterpriseOne business unit security provides the ability to filter data by business unit for UDCs and for transaction tables. For UDCs, you create subgroups of values that can be shared among various business units or might be unique to one particular business unit. This is referred to as UDC sharing. For transaction tables, business unit security enables you to limit the transaction records that a user can access based on business unit. This is called transaction security.

With UDC sharing, EnterpriseOne provides the ability to control or regulate how organizational data among different business units is shared.

Transaction security enables you to determine the transaction records a user can view. Transaction security ensures that users can only access and modify transaction data for the business unit to which they are associated.

You should set up business unit security when users are allowed to access data only for their business unit.

See Chapter 22, "Setting Up Business Unit Security" in this guide for more information on business unit security.

18.5 Authorization Security for User Defined Objects

EnterpriseOne enables you to set up security for objects created by end users, otherwise referred to as user defined objects. User defined objects include:

• EnterpriseOne Pages

• One View reports

• Related Information Application Framework (RIAF) objects

• Composite Application Framework (CAFE1) objects

• Queries

• Watchlists

For instructions on how to set up security for each type of user defined object, see the respective guides that describe how to administer each object:

• For Watchlists, see "Setting Up One View Watchlist Security" in the JD Edwards EnterpriseOne Tools One View Administration Guide.

• For One View reports, see "Setting Up One View Reporting Feature Authorizations" in the JD Edwards EnterpriseOne Tools One View Administration Guide.

• For CAFE1 objects, see "Setting Up the Composite Application Framework" in the JD Edwards EnterpriseOne Tools System Administration Guide.

• For RIAF objects, see "Setting Up RIAF for Generic URLs" in the JD Edwards EnterpriseOne Tools System Administration Guide.

• For EnterpriseOne Pages, see "Assigning Users, Roles, or *PUBLIC, and Publishing EnterpriseOne Pages" in the JD Edwards EnterpriseOne Tools System Administration Guide.

• For Queries, see "Working with Queries" in the JD Edwards EnterpriseOne Tools System Administration Guide.

18.6 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.

18.6.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.

18.6.2 Clearing the Cache on a Web Client Using Server Manager

To clear the cache on a web client for JD Edwards EnterpriseOne Tools 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 HTML 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