• No se han encontrado resultados

Capítulo II: MARCO TEÓRICO

2.2. MARCO LEGAL

2.2.3. Código de Derechos del Usuario Financiero

Allow access to launch Data Browser.

This option gives users access to the Data Browser, which they can use to perform personal or public queries.

Allow access to Search and Select for Tables or Business View Queries.

See Also:

■ "Viewing the Data in Tables and Business Views" in the JD

This option gives users the ability to search and select the table or business view that they want to query.

4. Click OK.

7.18.3 Removing Data Browser Security

You can remove Data Browser security using the Data Browser Security form or the Work With User/Role Security form. To remove security using the Data Browser Security form, clear the security check boxes for a user, role, or *PUBLIC. Using the Work With User/Role Security form, search for the security record and then delete the Data Browser security record from the grid.

7.19 Managing Published Business Services Security

This section provides an overview of published business services security and discusses how to:

■ Review the current published business services security records. ■ Authorize access to published business services.

■ Add multiple published business services security records at a time. ■ Delete published business services security.

7.19.1 Understanding Published Business Services Security

JD Edwards EnterpriseOne provides security to ensure that web service consumers are authenticated in the JD Edwards EnterpriseOne system and authorized to access published business services. The authentication of users of published business service users is handled by the Business Services Server and EnterpriseOne security server. After a user is authenticated by the JD Edwards EnterpriseOne security server, the system checks if the user is authorized to run a published business service by retrieving records from the JD Edwards EnterpriseOne F00950 security table, which contains all the object security records.

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. You manage published business services security using Security Workbench (P00950), the application used to manage all object security in JD Edwards EnterpriseOne. In P00950, you can add, copy, modify, or delete security records for published business

Note: This option is enabled only after you select the first option.

Note: To activate Data Browser security changes, you must refresh the jdbj security cache using the SAW.

Note: This section discusses only the authorization of users to access published business services.

services. When a user tries to access or run a published business service, verification of authorization is done through an API that queries records in the F00950 security table. As with all object security in JD Edwards EnterpriseOne, you can assign published business service security to a user, role, or *PUBLIC. You can create a security record that allows a user or role access to:

■ A particular method in a published business service. ■ All methods in a published business service.

■ All published business services.

It is recommended that you set up security by role first. This method makes setting up published business services security easier; instead of defining security for individual users, you can define security for the role and then assign users to the appropriate roles. If an individual in a role needs a different security setup, you can assign security at the user level, which overrides the role settings.

In addition, you can create a security record that disallows access to a published business service. Typically, there is no need to add security records that disallow access because by default, access to published business services is not allowed.

However, creating a security record that disallows access can be an efficient method to set up published business services security. For example, to allow a role access to all but a small subset of published business services, you can:

■ Enter *ALL in the fields for the published business service and published business

service method to create a security record that allows the role access to all published business services.

■ Create security records for the same role that disallows access to a subset of

published business services.

7.19.1.1 Inherited Security

When creating a published business service, a developer can configure it to pass its context to any published business service that it calls. In this configuration,

authorization for the called published business service is inherited; that is, if the calling business service is authorized, then the called business service is authorized as well. In this scenario, the system does not check the security for the called business service.

However, it is possible (though not supported) to configure a published business service so that it does not pass its context to another business service. In this scenario, the security or authorization for the called published business service is not inherited. Even if a user is authorized to access the calling or parent business service, the system also checks if access to the called business service is allowed. As a result, if there is not a security record that allows access to the called business service, the system will produce an exception or error, denying access to the called business service.

7.19.1.2 How JD Edwards EnterpriseOne Checks Published Business Services

Security

JD Edwards EnterpriseOne checks security for published business services in the same sequence that it checks security for all other JD Edwards EnterpriseOne objects—first by user, then role, and finally *PUBLIC. The system applies the first security record found. In addition, for the user, role, and *PUBLIC, the system checks for published business services security in this sequence:

■ Published business service. ■ *ALL.

This illustration shows how the system checks for published business services security for a user signed in with *ALL and a user signed in with a specific role:

Figure 7–3 *Role 1 has the highest role sequence.

Note: Using *ALL to set up object security in Security Workbench is not related to the *ALL functionality that is used to sign into JD Edwards EnterpriseOne. *ALL in Security Workbench enables you to assign a user, role, or *PUBLIC to all objects of a particular type. *ALL during sign-in enables users to sign into JD Edwards EnterpriseOne with all the roles that have been assigned to them.

User Id / Method + Published Business Service

User Id / Published Business Service User Id / *ALL

Sign-in Role / *ALL

Sign-in Role / Published Business Service Sign-in Role / Method + Published Business Service

*Public / Published Business Service

*Public / Method + Published Business Service

*Public / *ALL

User Signed In Using *ALL as Role User Signed In Using a Specific Role

User Id / Method + Published Business Service

User Id / Published Business Service User Id / *ALL

Role 1 / *ALL

Role 1 / Published Business Service

Role 1 / Method + Published Business Service

Role n / *ALL

Role n / Published Business Service

Role n / Method + Published Business Service

*Public / Method + Published Business Service *Public / Published Business Service

If a user is assigned to multiple roles and signs in as *ALL, the system uses role sequencing to determine which security record is used. A system administrator sets up role sequencing when setting up user and role profiles.

See Sequencing Roles.

7.19.1.3 Published Business Services Security Log Information

The log file provides administrators with information that you can use for

troubleshooting business service security without revealing details that could possibly create a gap in the security.

When a web service attempts to access a published business service in JD Edwards EnterpriseOne, the system records the authorization information in the log file. If the logging level is set to "Debug," the log file records whether authorization was granted or denied. If the log level is set to "Severe," the system only logs information if the attempt to access a web service fails. This is an example of the information provided in the log file:

Access to <method name> in <published business service name> is <granted/denied>⇒ for <user name> with <role name>.

See Also

Server Manager Guide for information on how to view business service security log

file information.

JD Edwards EnterpriseOne Business Services Server Reference Guide for information on

how to configure JD Edwards EnterpriseOne to authenticate users of published business services.

7.19.2 Reviewing the Current Published Business Services Security Records

You can use the Work With User/Role Security form in P00950 to review existing published business services security records. The query by example row of the grid enables you to display all security records for published business services. You can further narrow the search by locating the records for a user, role, or a particular published business service.

In addition, you can review published business services security records by running the Security Audit Reports—Security by Object (R009501) and Security by User/Role (R009502).

See Running a Report that Lists Published Business Service Security Records.

From the Security Maintenance menu (GH9052), select Security Workbench (P00950).

1. On the Work with User/Role Security form, enter S in the Security Type column

Documento similar