Several months ago, I worked with a customer who was rolling out a new version of an ecommerceWeb portal.The application, which is used primarily by the customer's partners, exposes sales data and other confidential information. The customer wanted to use SQL Server 2005 Reporting Services, but was concerned about security and report proliferation. Specifically, the customer wanted answers to two key technical questions: How can we use Reporting Services in an environment in which Windows Authentication isn't available and how do we deploy a common set of reports for the entire application—without the risk of one partner seeing another's data?
Because these questions are common in environments that deploy applications across the Internet or extranets, I'm going show you how to first, deploy a custom authentication scheme for Reporting Services and second, develop reports that filter data at run time based on which end user is viewing the reports.You can also use this filtering technique with Reporting Services' default security model.
Authentication and Authorization
Let's first quickly review the concepts of authentication and authorization.
Authentication is the process of establishing who you are, whereas authorization
is the process of determining what you can do. For example, when entering the
fitness club, I use my membership card to establish my identity (authentication).
Once inside, I have the privilege of using certain parts of the club (e.g.,
pool, tennis court) based on the authorizations I've been granted. Sadly, I
rarely make it the fitness club—but that's a topic for another article...
By default, Reporting Services 2005 uses Windows Authentication mode to establish identity and its own set of roles to grant privileges (referred to as Tasks) to Windows users or groups.This security model works well for companies that use Windows Authentication within the organization.
However, when it comes to providing reports outside the company firewall (or
when a company is trying to integrate with a different internal authentication
standard), Windows Authentication is often not an option. Fortunately, the Reporting
Services security model is extensible (like many other parts of the product).
In this case, the product's extensibility lets you replace the default Windows
Authentication mode with a custom authentication provider. Specifically, a developer
can implement the . NETbased IAuthenticationExtension security extension interface
to handle the job of authentication. We're going to do just that (and a bit
more) in this article. (For a discussion of using Web Services as an alternative
solution, see the sidebar "What About Web Services?")
Reporting Services Security Extension Basics
Reporting Services is built on top of the .NET Framework and uses a modular
architecture designed for extensibility.You can use .NET code to extend several
areas of the product, including report data sources, delivery, rendering, and
security. To leverage custom authentication, you implement the IAuthenticationExtension
security extension interface, and to use custom authorization, you use the IAuthorizationExtension
interface. From a deployment standpoint, your implementation of these interfaces
is compiled into a DLL.You deploy the DLL to the Reporting Services directory
and modify a set of configuration files accordingly.
Reporting Services 2000 used this security extension architecture, and it hasn't
changed much in the 2005 release. However, Microsoft has improved the architecture's
documentation and now provides a sample security extension. I'll let you read
the detailed explanation of the security extensions in SQL Server 2005 Books
Online (BOL) yourself, but here's a summary of the two extension interfaces
we'll be implementing:
IAuthenticationExtension. This interface represents an authentication
extension and contains the following three methods:
- GetUser—Returns the User Identity. In an Internet environment,
you'll typically get the user identity from the Web server's http context
(e.g., HTTPContext.Current.User.Identity).
- IsValidPrincipalName—Called when the Report Server sets security
on an item. You'll configure this method to query your custom store of users.
- LogonUser—Used to submit credentials to the Report Server for
authentication. After a successful call, the Report Server uses HTTP headers
to pass an authentication ticket (i.e., a cookie) from the server back to
the client.The client then uses this cookie for subsequent requests during
the remainder of the session. Figure 1 shows
a graphical flow representation of this process.
IAuthorizationExtension. This interface handles authorization
through three methods:
- CheckAccess—An overloaded method that determines whether a
user is authorized to access an item (e.g., a report) for a given catalog
operation (e.g., ExecuteReportDefinition). CheckAccess actually has 10 different
signatures, so to save time, I strongly recommend using the sample code as
a starting point.
- CreateSecurityDescriptor—Used to serialize the access-code
list applied to a report server item. Similar to an access control list in
Windows, the access code list contains the access rights each user has to
particular Report Server database items, such as folders or individual reports.This
method is used by the CheckAccess method.
- GetPermissions—Used by the Web service GetPermissions method,
this method returns the set of permissions granted to a specific user for
a given item.
Prev. page
[1]
2
3
next page 
