About the security model
All files stored in a BIRT iHub volume are subject to a standard security procedure, which restricts file access to authorized users. The iHub security model is based on roles and privileges. The iHub administrator creates roles for various job functions in an organization, such as finance, marketing, and sales. The privileges, or permissions, to perform certain operations, such as read, write, and execute, are assigned to roles. Users are assigned roles, and, through these roles, acquire the privileges to perform particular operations on folders and files.
With this level of security, each user has access to files and folders on a need‑to‑know basis. For security at a more detailed level, iHub provides the following types of security:
*Page-level security, which controls user access to particular sections or pages in a report. This security feature requires the Page Level Security option on iHub. The published report must be assigned the Secure Read privilege.
*Data security, which controls user access to a particular set of data provided by a BIRT data object. This security feature is part of the core iHub functionality. The published data object must be assigned the Secure Read privilege.
The security procedure that applies to files and folders in an iHub volume is implemented entirely in iHub. Page-level security and data security, however, require implementation in BIRT Designer Professional as well.
About access control lists and security IDs
Page-level and data security use the same security mechanism in BIRT Designer Professional: access control lists (ACLs).
An ACL is a list of security IDs that tells iHub which users have access to a particular item in a report or data object. A security ID can be either a user name or a role defined in iHub. Typically, you use roles because they are more permanent than user names. A role can be assigned to different users at different times as employees leave or change positions.
To implement page-level and data security in BIRT Designer Professional, perform the following tasks:
*In the report or data object, select the item to which to apply security.
*For the item’s Access Control List Expression property, specify an expression that evaluates to a security ID or a list of security IDs.
ACL expression syntax
The ACL expression must evaluate to a string, and can be either a JavaScript or EasyScript expression. If specifying multiple security IDs, separate each with a comma.
The following expressions are examples of ACL expressions in JavaScript. The first expression specifies a literal role name. The second expression specifies two literal role names. The third expression evaluates to role names, such as Sales Manager France or Sales Manager Canada. The fourth expression specifies two literal role names and an expression that evaluates to role names.
"CFO"
"CFO" + "," + "Sales VP"
"Sales Manager " + row["Country"]
"CFO" + "," + "Sales VP" + "," + "Sales Manager " + row["COUNTRY"]
The following ACL expressions are the EasyScript equivalent:
"CFO"
"CFO" & "," & "Sales VP"
"Sales Manager " & [Country]
"CFO" & "," & "Sales VP" & "," & "Sales Manager " & [Country]