Home » Archived » BIRT » Authorization
| Authorization [message #8960] |
Fri, 18 February 2005 17:24  |
Eclipse User |
|
|
|
Originally posted by: mbatchelor.no_s_p_a_m.pentaho.com
Hey all,
One thing haven't seen yet is any mention of authorization. How does one
assign access/viewing rights to specific sets of data?
Example:
User A is a member of the HR department. Users in the HR Department are
allowed to see all employees, and their details, but not any of the salary
information. User B is a manager of the development department. User B is
permitted to see salary information for all users that work for her, but is
not permitted to see salary information for her bosses or anyone in another
department and can't see HIPAA information under any circumstances.
Both receive a link to the report to view, and each sees different
information.
|
|
|
| Re: Authorization [message #8985 is a reply to message #8960] |
Sat, 19 February 2005 00:52  |
| Eclipse User |
|
|
|
Marc,
BIRT provides several features that let you implement your security model.
The first step is to define your security key. BIRT is designed to be part
of a J2EE server. Let's suppose that your J2EE session provides a user ID
and security group. You'd access these in BIRT through scripting. (We're
working out the exact details of how scripting will gain access to the J2EE
session.) Let's call these userID and groupID.
Next, we have to implement the actual security. There are a number of
choices.
The easiest is run-time row-level security. Use the userID or groupID to
parameterize your WHERE clause. The report would only show those rows to
which the user has access.
The next case is column-level security: hide certain columns from certain
users. This is the kind of security in your use case.
There are two ways to implement column security: run time or view time.
Run-time security works well for on-demand reports, or reports that only
one user will see. We control the data that goes into the report, then we
show that data at view time.
View-time security let's us create one report shared by all users, then
tailor the display depending on who is viewing the report.
Let's tackle run-time security. BIRT supports the idea of a computed column.
The value of the column can be computed using any arbitrary JavaScript
expression. We create a computed column whose value is either the column
you want to show (if the userID or groupID matches some attribute of the
row) or null if the user does not have permission. Null values will appear
blank in the report.
For the salary, suppose that each employee is assigned to a department
(deptID) and the user session identifies the department (if any) that the
user manages: mgrDept. Your computed column contains the salary if deptID ==
mgrDept, and null otherwise.
To implement view-time security, associate the security with the report item
that shows the column. In your use case, associate the data item with the
report item that shows the salary column. BIRT has a visibility expression
that determines when the item should appear. Use the user information to
determine whether the salary report item should be visible or not for any
given user.
Release 1 supports only on-demand reports: the person who runs the report is
the only person who can view the report. Hence, both run-time and view-time
security produce the same visual result. Later, when reports can be stored,
the difference between run-time and view-time security will be critical.
You can expand these techniques for other kinds of customization. You can
include entire subreports based on the run-time user. For example, a boss
gets a salary history for each employee in his department, but not for
employees in other departments.
And, these techniques work for non-security cases. For example, perhaps you
have a bug report that has options for "summary", "normal" and "detailed".
The user sets a report parameter with one of these choices. Based on this
parameter, your bug report shows different kinds of information. If summary,
only bug numbers & titles appear. If normal, then, say, bug number, title,
description, owner and status appear. If detailed, then the report also
includes comments, change history, and so on.
If you really want to go wild, you can even completely customize the report
before it runs. You can implement a method that will rewrite the XML file.
For example, the bug report above could provide lots of parameters for
"include owner?", "include history?", "include comments?", "layout type"
and so on. Based on this, you can generate a new XML design file on-the-fly
for a customized report. This is the file that the Engine will run. Sounds
complicated, but it can be a handy way to implement a highly customizable
report.
- Paul
Paul Rogers
BIRT PMC
"Marc Batchelor" <mbatchelor@no_s_p_a_m.pentaho.com> wrote in message
news:cv5puh$qm1$1@www.eclipse.org...
> Hey all,
>
> One thing haven't seen yet is any mention of authorization. How does one
> assign access/viewing rights to specific sets of data?
>
> Example:
>
> User A is a member of the HR department. Users in the HR Department are
> allowed to see all employees, and their details, but not any of the salary
> information. User B is a manager of the development department. User B is
> permitted to see salary information for all users that work for her, but
> is
> not permitted to see salary information for her bosses or anyone in
> another
> department and can't see HIPAA information under any circumstances.
>
> Both receive a link to the report to view, and each sees different
> information.
>
>
>
|
|
|
Goto Forum:
Current Time: Mon Jul 07 18:56:38 EDT 2025
Powered by FUDForum. Page generated in 0.36496 seconds |
Home