The Second Sample
To illustrate what my customer's environment ended up looking like, I built
another integrated sample of the CustomSecurity project (with three major parts)
for you to download and evaluate.The first part of this sample consists of a
custom ASP.NET Web site, FormsAuthSample, which uses Forms Authentication along
with the new ASP.NET 2.0 membership classes and login controls.The membership
classes provide a standardized way of validating user credentials, and managing
user settings against a custom data store such as SQL Server.The login controls
work on top of the membership classes. (For information about how to use these
features, see Rick Dobson's article "Making the Most of Login Controls with
ASP.NET," InstantDoc ID 93053.) Usernames and passwords are stored in a SQL
Server 2005 relational database, which I created by using the Aspnet_regsql.exe
tool (which creates a schema that the SQLMembershipProvider can use—see
Visual Studio 2005 documentation for more details).
To force the ASP .NET Web site to issue a persistent cookie to the user, I
set the RememberMeSet property of the Login-Control to true and set the DisplayRememberMe
property to false. This means that in a production environment, you'd need to
first determine whether the user's browser is configured to accept cookies.
The FormsAuthSampleWeb site uses the AdventureWorks sample database as a data
source for reports and is designed as if the AdventureWorks company decided
to set up an extranet for its vendors. Thus, when you're using the Web site,
it will be as if you're a vendor.
Note that when you're testing or debugging this Web site, you need to make
sure you run it inside Microsoft IIS—don't use the Visual Studio 2005
built-in Web server. This point is important because, as I previously mentioned,
you need to avoid the use of localhost in your URLs and instead target your
machine name. You can still debug inside of Visual Studio, but make sure you
open the Web site from Local IIS, not from the File System, as Figure
2 shows. You'll also want to change the StartUrl (located on the Start Options
tab of the Project Properties dialog box) to reflect your machine name.
The second part of my updated sample is an implementation of the CustomSecurity
project. My changes to the original version resulted in three key differences:
- The two logon pages are left in place but they redirect the user to our
Web site's login page.
- The LogonUser method calls a Web service (hosted in our Web site) to verify
the username and password. Note that LogonUser is now no longer invoked by
end users (or our Web site), because our Web site handles user verification
and the issuing of cookies. But Visual Studio or the Reporting Services Web
service uses the LogonUser method when you're deploying reports from Visual
Studio; the method would be called if you wanted to use a Reporting Services
Web service API.
- The IsValidPrincipalName method calls a Web service (hosted in our Web site)
to verify usernames.
To work with the updated version of the CustomSecurity project, you can simply
copy the updated .dll to the two Reporting Services bin directories. You'll
also need to update the authentication element and add a machineKey element
to the ReportServer web.config file, as the code in Listing
1 shows.
Finally, the third part of the updated sample is the set of reports we'll use
to demonstrate report filtering (RSFormAuth-Sample). In the article download
at InstantDoc ID 93830, find and open the RSFormAuth-Sample project in Visual
Studio and update the Target-ServerURL property accordingly.Then, deploy the
project to your report server. You'll be prompted to enter credentials; use
the Admin username and password you created.
With everything deployed and configured, you should be able to start the FormsAuthSample
Web site, login, and view reports from the My Account page, the ReportManager,
or the Report Server URL without having to login again. If you later navigate
directly to the ReportManager and your cookie has expired or you've deleted
the cookie, you should be redirected to the FormsAuthSample login page. Pretty
cool!
Report Filtering
Once forms-based authentication is working, we can focus on the problem of how
to filter reports so that users see only their own data. The solution to this
problem is actually fairly straightforward. Every time a user executes a report,
Reporting Services exposes a set of global values, one of which is User!UserId,
which represents the name of the person executing the report. Depending on the
nature of your source data, you might be able to pass this value into your query
to filter the resulting dataset. Reporting Services 2005 makes this approach
a bit easier than Reporting Services 2000 does because it lets you specify parameters
as "Internal." Thus, you can set the default value of a parameter to User!UserId
and use the parameter in your SQL statements. All the while, the user will never
see (nor be able to modify) this parameter.
To see filtering in action, first log in to the FormsAuthSample Web site as
an Administrator, noting the two Vendor user accounts listed at the bottom of
the Login screen. In the Report Manager, add these two accounts to the Home
folder as Browsers.Then, log out and log back in to the application, this time
using one of the Vendor accounts. Next, take a look at any of the three sample
reports provided. As Figure 3's
example shows, you'll see only the information that's allowed for the Vendor
account you selected.
Putting Extensibility to Use
The broad extensibility of Reporting Services 2005 is something you don't always
find in other software applications. I hope that after reviewing this article
and its accompanying code samples, you're excited and comfortable with the idea
of using Reporting Services both within and outside your organization.
End of Article
Prev. page
1
2
[3]
next page -->
