My preferred method to block user's from seeing other peoples data - especially sales and financial data, is using AD logins on the report server. The AD policy forces password changes regularly so its not that easy for others to get in with "other" credentials. My end-users are generally quite IT illiterate so I depend on AD to lock them down and keep out of each others figures. So far its worked well.
But yes, if one of them had to "steal" or guess a login then they would get in to that users data. Same goes for their email or windows profile and documents. Worst case (on SSRS) they get to see one other user's sales figures. The data source they're connecting through is using fixed credentials, with execute on a single SP, so that should be secure enough to block a "hacker" from getting further than that result set.
I didn't want to give them too many user names and passwords to fill in as it does mean more support work for their IT department.
Sorry, I was referring to the method presented in the article. There's no problem using the Global USerid to filter records on a report because that would require the user to know both username and password to actually log in as that user. I was referring to the use of a parameter to store the username and filter based only on the parameter as the only security method in place. With the method in the article I can open the website via a URL and add &rs:Command=Render&User=domain\userwithprivs and bingo I'm in. I'm thinking that a SOX or HIPPA (or insert your country's Laws that define auditing regulations) auditor may find some very large issues with this.
This is compounded by the use of domain login names as email addresses in some companies. If I know your email address, then I know your Username so it makes it very easy to defeat it. I now have every piece of information that I need to defeat the security model presented in the article.
To help us help you read this
For better help with performance problems please read this