The BRIOSECG table defines the users and groups that are subject to row‑level security restrictions. There are two columns, BUSER and BGROUP, both of varying character length (VARCHAR(n)). The maximum length is not fixed by the server; set it to a practical value.
A user name is defined as the server authentication name (ODSUsername is the property of the ActiveDocument object in the Interactive Reporting Object Model). For jobs, it is the user who scheduled the job.
Group names are arbitrary. The data security administrator is free to define these as required. When both columns of a row are populated with non-null values, the user name defined in the BUSER column is a member of the group name defined in BGROUP.
As maintained by the sample Interactive Reporting document row_level_security.bqy, when a user is added, a row is added to the table with a NULL value in the BGROUP column. When a group is added, a NULL value is stored in the BUSER column. This is a device used by the Interactive Reporting documents to maintain the table and is recommended practice, but it is not a requirement for correct operation of row‑level security.
This table is theoretically optional. Without it, however, all users exist as single individuals; they cannot be grouped to apply a single set of restrictions to all members. For example, Vidhya and Chi are members of the PAYROLL group. If this relationship is not defined in BRIOSECG, then any restrictions that apply to Vidhya that should also apply to Chi have to be defined twice. By defining the PAYROLL group and its members, Vidhya and Chi, the restrictions can be defined only once and applied to PAYROLL group.
A group name cannot be used in BUSER; that is, groups cannot be members of other groups. Users, of course, can be members of multiple groups, and this can effectively set up a group/subgroup hierarchy. For example, a PAYROLL group might contain users Sally, Michael, Kathy, David, Bill, Paul, and Dan. Sally, Dan, and Michael are managers, and so they can be made members of a PAYROLL MANAGER group. Certain restrictions on the PAYROLL group can be overridden by the PAYROLL MANAGER group, and Dan, to whom Sally and Michael report, can have specific overrides to those restrictions placed explicitly on the PAYROLL MANAGER group.
Where the database supports it, and if the user’s authentication name in Reporting and Analysis corresponds, this table can be a view created from the roles this user has in the database. For example, in Oracle:
DBA_ROLE_PRIVS is a restricted table. Since the server reads the view using a configured database logon, it would not be appropriate to use USER_ROLE_PRIVS instead of DBA_ROLE_PRIVS, because that user view will reflect only the server’s roles, not the user on whose behalf the server is operating. Again, this is an Oracle example; other RDBMS may or may not provide a similar mechanism. In some cases, depending on the database, a stored procedure could collect the role information for the users and populate a BRIOSECG table if a simple SELECT is inadequate to collect the information. This would require some means to invoke the procedure each time role definitions were changed.
When using the database’s catalog or some other means to populate BRIOSECG, the sample Interactive Reporting document, row_level_security.bqy, cannot be used to maintain user and group information.
A special group, PUBLIC, exists. It does not need to be explicitly defined in BRIOSECG. All users are members of the PUBLIC group. Any data access restriction defined against the PUBLIC group applies to every user unless explicitly overridden, as described later.
All users can be made part of a group at once by inserting a row where BUSER is ‘PUBLIC’ and BGROUP is that group name. While this may seem redundant, given the existence of the PUBLIC group, it offers some benefits:
It allows the database catalog technique described above to work. For example, in Oracle, a role can be granted to PUBLIC.
It allows restrictions for a group other than PUBLIC to quickly be applied to or removed from everyone in an instant.
It provides more flexibility when using override specifications as described later.