When I first reviewed the security extensions, I wondered whether it was really
necessary to implement IAuthorizationExtension. For example, suppose I'm interested
in replacing Windows Authentication with Forms Authentication, but I don't want
to replace the built-in roles and tasks that my authentication mode uses for
authorization. It turns out that you do need to implement the authorization
extension. Fortunately, you can still use the roles and tasks within your authorization
logic, and this is what we'll do in our samples. Now that we have a basic understanding
of the interfaces, we're ready to dive into a sample implementation.
Getting Started: Installing the Sample Security Extension
We're going to start by installing the CustomSecurity sample security extension
that ships with SQL Server 2005. (Note that samples aren't installed automatically
during setup. For instructions about how to install the samples, see the BOL
topic "Installing Samples.") The default location of the CustomSecurity
sample, which uses Forms Authentication, is the Extension Samples\ FormsAuthentication
Sample subdirectory of the Reporting Services Samples directory. So the
path looks like this:
C:\Program Files\ Microsoft SQL Server\90\Samples\ Reporting Services\ Extension
Samples\ FormsAuthentication Sample.
The sample is available in both C# and VB.NET versions.
A few words of caution before you begin. First, be aware that implementing
a security extension isn't necessarily complex, but it does require several
manual steps. Except where I've noted in my tips below, you'll want to carefully
follow each step of the BOL topic "Security Extension Sample [Reporting
Services]" to deploy the sample. In the sample subdirectory, you'll also find
a Readme file that's the same as the BOL topic except that the Readme
file incorrectly repeats some of the initial deployment steps.
Second, you'll see that BOL warns, "Reverting back to Windows Authentication
after migrating to a different security extension is generally not recommended."
I suggest that you install a new named instance of Reporting Services 2005,
which you can uninstall later without affecting any existing instances.
Third, when I went through the sample, I encountered a few problems that I
don't want you to have to work through.To save many hours, while installing
the sample, keep the following tips close:
- The VB.NET sample (Authorization .vb) contains errors in its implementation
of IAuthorizationExtension. To work around these errors, use the C# sample
code or download the updated version of Authorization .vb that's included
in this article's download .zip file at http://www.sqlmag.com,
InstantDoc ID 93830.
- The Building the Sample section of the sample directs you to generate a
strong key file but doesn't tell you what to do with the key file. After you
generate the file, you need to update the Strong key file path of the Project.
To point to your new key file, select the Project, CustomSecurity Properties
menu item, navigate to the Signing tab, then select the <Browse...>
item in the Choose a strong name key file: drop-down box.
- Don't use localhost in the RSWebApplication.config file or during testing.
Instead, always use your machine name (e.g., http://yourmachinename/ReportServerFA).
Once you've built and deployed the sample code and modified the necessary configuration
files, you should be able to navigate to the sample screen that lets you create
and register an initial administrative account and log on from the Report Manager.
Microsoft also provides a second logon screen for the ReportingServices URL.
These sample logons obviously aren't secure or production-ready, but they offer
a simple way to get started.Take some time to create additional non-administrative
accounts (e.g., add them to the built-in Browser role in the Home folder) to
verify the authorization extension logic is also working properly.
Not Quite What We Wanted
I distinctly remember my first impression after working through the sample:
This isn't quite how my customer wants things to work.The customer already had
an application with its own login screens, so we didn't want to create additional
login screens within Reporting Services. My customer also didn't want end-users
to have to log in twice (once for the application, again for Reporting Services).
After further review of the sample extension, we began exploring the option
of having the application and Reporting Services share a cookie to manage requests
after a client has been validated. ASP.NET supports forms authentication in
a distributed environment, so this is the route we decided to take. (For information
about this functionality, see the Microsoft article "Forms Authentication Across
Applications" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconformsauthentication
acrossapplications.asp.) The key to configuring this distributed authentication
(which you can see in action in my second downloadable sample at InstantDoc
ID 93830) is setting a few identical attribute values in the Forms element of
each application's web.config file (and adding an identical MachineKey element).
Prev. page
1
[2]
3
next page 
