Enforcing Security in reports [message #127279] |
Thu, 09 February 2006 12:23  |
Eclipse User |
|
|
|
Originally posted by: nadeemabbasi1.yahoo.com
I have looked thorugh the newsgroup to see if any discussions have taken
place on security, but did not find any. Here is my question. What are
people doing to ensure that when two users access the same report via the
Report Viewer, the data presented in the report is based on the security
access granted to each user? Here is a scenario. Two users login to a
J2EE app that authenticates these users against a data store and
determines their access rights based on the security groups they are
assigned to. Within the app there is a URL link to a BIRT report that one
person can access, and the other person cannot. However, if the person
that cannot see this link within the app knows the URL to the BIRT report,
he can simply type that in a browser window and access the report
bypassing the app's security. What options are available in BIRT to
address this security issue? I have heard elsewhere that if we pass the
user's login id or security group names as parameters to the report, these
can be used in the SQL WHERE clause to restrict the rows shown in the
report - but again since these parameters are readily available in the
URL, it can be used by anyone that knows that URL. Any ideas?
Thanks.
|
|
|
|
Re: Enforcing Security in reports [message #127433 is a reply to message #127279] |
Thu, 09 February 2006 12:53   |
Eclipse User |
|
|
|
Originally posted by: rdubey.mantech-ist.com
There are some of several things you can try:
1. Authenticate the user and apply security in a servlet that redirects to
the BIRT reporting URL (or any other URL). Never present a real BIRT URL in
your application but always "front" the URL through your servlet which
authenticates the user and assesses his level of access first. This is very
portable, but the disadvantage is that the data is not protected unless the
user uses the new servlet. You also need a certificate you can extract or
for the user to otherwise pass his credentials or login first
(authenticate).
2. Authenticate and allocate permissions on a URL basis via the Web Server.
Very tedious, but once you authenticate you can allow/disallow users and or
groups of users access on a URL basis. This has the disadvantage of being
webserver specific and thus is harder to maintain..
3. Authenticate the user and send his credientials in the database itself by
connecting as that user. The database can then via stored procedures or
label security/ virtual private database decide what the user can access.
The advantage with this is that your security can be data-centric, and the
data is protected regardless of which application tries to access it. The
disadvantage is this is usually very database-specific and you usually need
a database account for every user and/or group. If you know you'll always
be using Oracle, for example, then great, otherwise this is not protable.
If you have the time and resources, this is the best solution IMO for
protecting/restricting data.
I use a combination of #1 and #3, in fact I never connect directly via BIRT,
I connect as the user in my Struts Action and pass the resulting data (as a
disconnected resultset, a business object, or a vector of Java.Sql.Row
objects) to BIRT and use scripting instead.
Just a few ideas... good luck,
Ravi
"Nadeem" <nadeemabbasi1@yahoo.com> wrote in message
news:ff941a158c5c991566332c928cac16c0$1@www.eclipse.org...
>I have looked thorugh the newsgroup to see if any discussions have taken
>place on security, but did not find any. Here is my question. What are
>people doing to ensure that when two users access the same report via the
>Report Viewer, the data presented in the report is based on the security
>access granted to each user? Here is a scenario. Two users login to a
>J2EE app that authenticates these users against a data store and determines
>their access rights based on the security groups they are assigned to.
>Within the app there is a URL link to a BIRT report that one person can
>access, and the other person cannot. However, if the person that cannot
>see this link within the app knows the URL to the BIRT report, he can
>simply type that in a browser window and access the report bypassing the
>app's security. What options are available in BIRT to address this
>security issue? I have heard elsewhere that if we pass the user's login id
>or security group names as parameters to the report, these can be used in
>the SQL WHERE clause to restrict the rows shown in the report - but again
>since these parameters are readily available in the URL, it can be used by
>anyone that knows that URL. Any ideas?
>
> Thanks.
>
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04003 seconds