Enforcing Security in reports [message #127279] |
Thu, 09 February 2006 17: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 #127348 is a reply to message #127279] |
Thu, 09 February 2006 17:39 |
Eclipse User |
|
|
|
Originally posted by: fgheorghe.eprimepoint.com
Nadeem,
You can get around this issue by using the BIRT engine api's to run
your report instead of running them from the url. For example your link
to run the report would actually point to a jsp or a servlet that would
check the session to see who the user is (and whether they are allowed
to run the report) and then it would call a java class which actuall ran
the birt report and streamed the output back through an html context.
You can actually take the security one step further by using the
addScriptableJavaObject() method to pass back to BIRT only rows which
have been determined that this particular user can see.
Nadeem wrote:
> 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 17: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.
>
|
|
|
Re: Enforcing Security in reports [message #127474 is a reply to message #127433] |
Thu, 09 February 2006 18:24 |
Eclipse User |
|
|
|
Originally posted by: nadeemabbasi1.yahoo.com
Thanks for the great suggestions. One question though. You mentioned
that you can "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." How do you design the BIRT report to work with things
such as these? Does this involve using the "Scripted Data Source" where
the report calls a Java class to "fetch" the data? If not, than can you
please point me to the appropriate documentation that describes this
approach?
Thanks again.
-nadeem
|
|
|
Re: Enforcing Security in reports [message #127513 is a reply to message #127474] |
Thu, 09 February 2006 18:46 |
Eclipse User |
|
|
|
Originally posted by: fgheorghe.eprimepoint.com
Nadeem,
Yes. You would create a scripted data source. Inside of the "open"
and "fetch" methods you can reference a java object (ie
objMyJavaObject). Then in your java code (where you create the report
engine and run the report) you would use the
addScriptableJavaObject("objMyJavaObject",someJavaClass) method to
expose your java class which would probably contain a vector or array
which has your data.
for example (this code wont be ideal but you'll get the idea):
Your java class might look something like this :
public class someJavaClass
{
ArrayList data = new ArrayList();
public ArrayList getMyData()
{
person p = new person();
p.firstName = "A";
p.middleName = "B";
p.lastName = "C";
data.add(p);
.
.
.
return data;
}
class person
{
public String firstName;
public String middleName;
public String lastName;
public String getFirstName(){return firstName;}
public String getMiddleName(){return middleName;}
public String getMiddleName(){return lastName;}
}
}
Data Set "open" method would contain something like this :
myDataList = objMyJavaObject.getMyData();
Data Set "fetch" method would contain something like this :
var currentItem = myDataList.get(currentRow);
row["FIRST_NAME"] = currentItem.getFirstName();
row["MIDDLE_NAME"] = currentItem.getMiddleName();
row["LAST_NAME"] = currentItem.getLastName();
currentRow = currentRow + 1;
Now the java code that calls birt would look something like this :
IRunAndRenderTask task = engine.createRunAndRenderTask(
report );
...
//you can find sample code for calling birt through api's
//in this newsgroup
...
someJavaClass sjc = new someJavaClass();
task.addScriptableJavaObject("objMyJavaObject", sjc);
try
{
task.run( );
}
catch (EngineException e)
{
}
I might have left some things out but I hope you get the idea.
Florin
Nadeem wrote:
> Thanks for the great suggestions. One question though. You mentioned
> that you can "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." How do you design the BIRT report to work with
> things such as these? Does this involve using the "Scripted Data
> Source" where the report calls a Java class to "fetch" the data? If
> not, than can you please point me to the appropriate documentation that
> describes this approach?
>
> Thanks again.
>
> -nadeem
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03516 seconds