A connection-scope security policy is used to refer to a data source security entry in a catalog. It allows you to control user access to different subsets of data, and ensures that people only see what they are supposed to see: certain records and/or columns.
If you want to implement the same security policy in a group of reports, you can simply apply an existing security policy to the reports, without having to repeatedly build the security information for each report. The following diagram illustrates the security structure of the connection-scope security policy.
For example, if user U1 belongs to two roles and two groups, such as R1, R2, G1, and G2. The permissions he/she will have are the permissions collections of the roles, groups and itself, which is P1, P2, P3, P4, and P5, as shown in the following diagram.
The group and role relationships are the same. Here is another example, if group G1 has two roles, R1 and R2, together with its own permissions, the users in group G1 will have P1, P2, and P3, and also the permissions assigned directly to the users.
When calculating a user's permissions, the permission collections of its roles and groups are first calculated using logical OR. If the calculation result conflicts with the user permissions, the user's permissions will have priority. That is, if one access right is permitted for the user's groups and roles but denied by the user's permissions, the user will not be permitted to have this access right.
The major steps for using RLS and CLS with a connection-scope security policy are as follows:
You use this step to set up the security policies for different report categories. The predefined security policies work within a connection range.
After you have defined the security policies, you can then apply them to your reports respectively.
Pick a task from the following: