Focus on Microsoft Technologies - Tutorials, Articles, Code Samples.

Thursday, September 21, 2006

Authentication, Role-based Security, and SQL Reporting Services Web Services

Credentials and ASP.NET
Determing what DefaultCredentials represents in an ASP.NET environment is more difficult. In a default installation, with no impersonation in place, DefaultCredentials will be the credentials for the ASP.NET process. The ASP.NET process runs as the ASPNET account (in IIS 5.0), or the
NETWORK SERVICE account (in IIS 6.0). At this point we need to break down the scenario into local reporting server versus remote reporting server environments.

Local Server

If the web application is on the same server as the Reporting Services web service, the call will authenticate using DefaultCredentials, but you are probably seeing the “permissions are insufficient” exception. One solution to this problem is adding the ASPNET or NETWORK SERVICE account into a role in Reporting Services, but take care before making this decision. If you were to place the ASPNET account into the System Administrators role, for example, anyone with access to your web application is now a Reporting Services administrator.

Alternatively, you can use impersonation in ASP.NET. You can enable impersonation for the application, for a subdirectory of pages, or for individual pages, using the identity element in web.config (see more resources for additional information). When using impersonation, it is important to deny access to anonymous users, as shown below:
    <authentication mode="Windows"/>
    <identity impersonate="true"/>
        <deny users="?"/>
        <allow users="*"/>

WIth impersonation the ASP.NET page will execute with the security context of the client, and web service calls to the same machinewill also be made with the security context of the client (using DefaultCredentials). You will still need to configure role-based security for each user to give each user authorization to perform actions.

Remote Server

When a web application makes web service calls to a remote report server, there are additional complications. If you are using impersonation, there is a one-hop limit with NTLM authentication. The client’s credentials make one hop from the client machine to the web server, and ASP.NET can use these credentials to impersonate the client on the same machine only. For ASP.NET to use the credentials on another remote machine would require the credentials to make a second hop, which does not happen - the call will go to the remote machine with the credentials of the ASP.NET process instead. Since the ASP.NET process runs under a local machine account by default, the remote server will not authenticate the credentials and the call will fail with an access denied message.

There are a number of solutions in this scenario.

First, you can look at enabling Kerberos delegation, which is beyond the scope of this article, but you can read about delegation in the article How To Configure an ASP.NET Application for a Delegation Scenario. Using delegation would allow you to have the client’s credentials make the additional hop to reach the report server, which in turn gives you more granular control over authorizations by placing users and groups into roles instead of process accounts.

Another option is to run the ASP.NET process under an account with permissions to the report server. For example, the ASP.NET process could run under a domain account. For details, see the article: ASP.NET Process Identity. A similar strategy would be to synchronize the ASPNET / NETWORK SERVICE accounts on both the application server and the reporting server by matching thier passwords and configuring ASP.NET to use the password. Using these options you’ll need to add the ASP.NET process account into a role on the report server. Unfortunately, anyone with access to your web application will now be in this role, so your application will become responsible for more granular authorization checks.

Finally, you can pass credentials from ASP.NET to the reporting server using the NetworkCredential class shown earlier in the article. All the same caveats apply in regards to storing a username and password in code or in an XML config file.

Once you’ve avoided all of the access denied messages, it’s time to configure role-base security.

Post a Comment