How Data Resources and Data Security Policies Work Together
A data security policy applies a condition and allowable actions to a data resource for a role. When that role is provisioned to a user, the user has access to data defined by the policy.
In the case of the predefined security reference implementation, this role is always a duty role.
The data resource defines an instance of a data object. The data object is a table, view, or flexfield.
Data Resources
A data resource specifies access to a table, view, or flexfield that's secured by a data security policy.
-
Name providing a means of identifying the data resource
-
Data object to which the data resource points
Data Security Policies
Data security policies consist of actions and conditions for accessing all, some, or a single row of a data resource.
-
Condition identifying the instance set of values in the data object
-
Action specifying the type of access allowed on the available values
If the data security policy needs to be less restrictive than any available data resource for a data object, define a new data security policy.
Actions
Actions correspond to privileges that entitle kinds of access to objects, such as view, edit, or delete. The actions allowed by a data security policy include all or a subset of the actions that exist for the data resource.
Conditions
A condition is either a SQL predicate or an XML filter. A condition expresses the values in the data object by a search operator or a relationship in a tree hierarchy. A SQL predicate, unlike an XML filter, is entered in a text field in the data security user interface pages and supports more complex filtering than an XML filter, such as nesting of conditions or sub queries. An XML filter, unlike a SQL predicate, is assembled from choices in the UI pages as an AND statement.
An XML filter can be effective in downstream processes such as business intelligence metrics. A SQL predicate can't be used in downstream metrics.