The system restricts access to its transactions as follows:
An application service may be associated with every securable function in the system.
All maintenance objects define an application service that includes the basic actions available, typically Add, Change, Delete, and Inquire. The base product supplies an application service for every maintenance object.
For maintenance objects whose user interface page is not portal-based, the application service also controls whether the menu entry appears. If a user doesn't have access to the maintenance object's application service, the menu item that corresponds with the application service will not be visible.
For portal based user interfaces, each main portal defines an explicit application service with the access mode Inquire, allowing the user interface to be secured independently of the underlying object security. If a user doesn't have access to the portal's application service, the menu item that corresponds with the application service will not be visible. The base product supplies an application service for every portal that is accessible from the menu.
Menu items may define an application service. Use this technique for the following scenarios:
Suppress a menu item if the underlying application security for the transaction does not provide enough fine grained control. For example, imagine your implementation creates a special BPA script to add a To Do Entry and would like users to use the special BPA rather than the base supplied Add dialogue for To Do Entry. The underlying security settings for To Do Entry should grant Add access to these users given that the special BPA will still add a record. To suppress the base Add dialogue, link a special application service and access mode for the base supplied menu item for To Do Entry Add. Then define a menu entry for the new special BPA for adding.
Suppress the add option if a user does not have add security for the object. By default the product does not suppress the add function if a user does not have add access to the object. Rather, the user is prevented from adding the record at the back-end. If your implementation would like to suppress the icon, link the object's application service and the Add access mode to the Add menu item.
Zones define an application service
For zones linked to a portal, if a user doesn't have access to the zone's application service, the zone will not be visible on the portal. In most cases the zone defines the same application service as its portal. In special cases, such as the zones on the Dashboard, the product supplies separate application services for each zone allowing implementations to determine at a more granular level which users should have access to which zones.
For query zones that are configured on a multi-query zone, if a user doesn't have access to the zone's application service, the zone will not be visible in the dropdown on the multi-query zone. In most cases all zones in a multi-query zone define the same application service as the multi-query zone. The product may supply a special application service for one or more zones in a multi-query zone if the functionality is special to certain markets or jurisdictions and not applicable to all implementations.
For zones that are used by business services to perform SQL queries, the product supplies a default application service. Security for these zones is not checked by the product as they are used for internal purposes.
Business objects define an application service. If the business object defines a lifecycle, the application service must include access modes that correspond to each state. In addition, the standard maintenance object access modes of Add, Change, Delete and Inquire are included. The base product business objects are supplied with appropriate application services.
Other configuration tool objects are securable but the base product typically does not supply special application services for each object. An implementation may supply custom application services and link them to the appropriate record:
BPA scripts may define an application service with the access mode Execute. The base BPA scripts are typically not configured with any application service. An implementation may define one. Note that as mentioned above, a menu item may also be configured with an application service and access mode. This allows for a BPA that is invoked via a menu entry to be secured in more than one way.
Business Services and Service Scripts define an application service with the access mode Execute. This is needed for services that may be executed from an external system, for example via an inbound web service. Base business services and service scripts are configured with a default application service, which may be overridden by an implementation.
Users are granted access to application services via user groups. For example, you may create a user group called Senior Management and give it access to senior manager-oriented pages and portals.
When you grant a user group access to an application service with multiple access modes, you must also define the access modes that are allowed. Often the access modes correspond to an action on a user interface. For example, you may indicate a given user group has inquire-only access to an application service, whereas another user group has add, change, cancel and complete access to the same service. Refer to action level security for more information.
If the application service has field level security enabled, you must also define the user group's security level for each secured field on the transaction.
And finally, you link individual users to the user groups to which they belong. When you link a user to a user group, this user inherits all of the user group's access rights.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]