Prologika Forums

In the book and your devx article it assumes that the reports are tied to users or groups which are given access to the reports.  Because we are integrating RS with a legacy app which has its own complicated permissions structure I want the ultimate decision to be based on the data in the legacy application database.  The legacy app does not use .NET and reports will be a combination of legacy reports, RS reports and possibly other reports as well.  Currently users are given permissions to legacy reports in the legacy app (without using .NET nor webservice calls to RS) and I'd like it to remain that way--at least for the present.

Therefore in CheckAccess() I need to know the item or report the security descriptor details (secDesc) is describing so I can look up if the user has rights to the report in the legacy app (which has a listing of RS reports--among others).  Is there any way to get that?

Since I am mainly interested in securing the reports I could infer the report from the URL QueryString but this seems like the worst way of approaching it.

 

 

 

 

I can't debug the extension because my local server is not set up for for custom authentication but if the secured resource (report) is not included in the security descriptor then you may not have other options. As a side note, if you have another application facade on top of RS, e.g. web application, you could simplify your security setup a lot by letting the application authenticate and authorize the user and using a trusted account to the report server.

The problem is in checkAccess the secDesc is type byte[] dimension[8192].  This means very little to me.  I'm thinking there must be some sort of method or something to make sense of it --but specifically what it is securing.

While the aceCollection desterilizes the secDesc (AceCollection acl = DeserializeAcl(secDesc);) and thus does make sense of it, the aceCollection seems to describe who can see the resource but has no detail about the resource itself.

Maybe I'm missing something and there is a point checkAccess that I can intercept/overload--where the secDesc is being created--but I haven't been able to find one.  Understanding you don't have it to hand--any thoughts on directions to look would be more than welcome.

Your side note makes sense.  We are doing the authentication and initial authorization in the other app.  However, we need to securely pass in a userID (from our bespoke database) in order to do filtering on the data presented in the report. It is complicated but the logic is almost on a user basis (e.g.a users can see data of people who live next to them)  and we are using URL access as well.  In order to use the trusted account I was thinking we'd need to access RS via web services which got complicated.  While we could probably manage the initial authentication via webservices and get the token...as far as I could tell that access (which could be via a trusted account) wouldn't let us security pass in the userID so on subsequent accesses, RS wouldn't know who it was.

What we were intending to do is something along the lines of having the .NET custom security validate the existing cookies (from our other web app--same domain) instead of providing a username/password for authentication.  But,  as far as I can see we still need to authorize with URL access...so I still need to work out what report is being accessed.

 
As I said, even if they aren't definitive, any thoughts which come to mind on approaches would be more than welcome. 

Unfortunately, as explained in more details here (http://technet.microsoft.com/en-us/library/ms152800(SQL.90).aspx), the security descriptor doesn't include information about the secured resource. Sounds like custom security is the way to go in your scenario. You may need to parse the request URL to extract the report path.

Thanks for you comments. 

Parsing URL is is working well enough except that the actual URL-driven report returns with Iframes --and some of the underlying pages don't have the same report query string.  The path being returned for these "other" pages is something like  /ReportServer/Reserved.ReportViewerWebControl.axd and the query string containing the following parameters which do not obviously link to the report.

ExecutionID,ControlID, Culture, UICulture, ReportStack, OpType, Interval

Do you happen to know if there any way of tying it back to the report so that specific permissions for that can be checked?  It is going through checkAccess as well.

 

 

It turns out that passing the secured resource is on the wish list for a future release. Currently, there is no way to obtain it from the server in CheckAccess.

Good to know