Configuring iHub security : Working with RSSE page-level security : About the RSSE page-level security example
 
About the RSSE page-level security example
Using the RSSE framework, a developer can create an RSSE service that manages page-level security by retrieving a user’s access control list (ACL) externally. By default, when a secure design asks for the ACL of a user, the Encyclopedia volume returns a list that includes the user ID and the roles to which the user belongs. Frequently, the information in iHub security does not match the information in a database used by a secure design. An RSSE page security application can translate an iHub ACL to a design-specific ACL.
iHub Integration Technology contains an example of how external page-level security works using RSSE. This example is located under the Java Report Server Security Extension directory in the subdirectory, Page_Security_Example.
To use page-level security, license the BIRT Page Level Security option. The example RSSE page-level security application uses a text file, users.acls, that maps Encyclopedia volume user names to other external security IDs. Use the sample application as a basis for a custom RSSE application.
Page-level security protects a report from unauthorized access by comparing the user ID and user membership in Encyclopedia volume roles to an access control list (ACL) for the report document. If the user’s name appears in the ACL, the user can view the protected pages.
The RSSE application uses a file, users.acls, to translate an Encyclopedia volume user ID or role to one or more security IDs, which iHub uses to check against the Actuate report page ACL when a report uses page-level security.
For example, if a report shows information about the sales reps in the following city offices:
*NYC
*Boston
*Philadelphia
and the file, user.acls, contains the following access control list specifications:
user1=NYC
user2=Boston
user3=Philadelphia
then user1 has access to the pages with information about NYC office, user2 to the Boston office, and user3 to the Philadelphia office.
In this example, when user1 tries to read a report with page-level security enabled, the RSSE application returns a list of security IDs that contain user1 and user1’s roles. iHub checks the user ID, roles, and RSSE list against the Actuate report page ACL. iHub lets user1 view any report page where a security ID that the RSSE application returns matches a report page security ID.