Release Date: 8/18/2004
| Update Date: 8/18/2004
Microsoft Corporation
Scope of application: Microsoft® SQL ServerTM 2000 Reporting Services
Summary: Learn about Reporting Services security extension, focus on learning form authentication. In addition, downloading and deploying a form authentication extension example of Reporting Services.
To install the sample code, download the Forms Authentication Sample Installer and run it on your computer.
This page
Introduction About this Guide Reporting Services Platform Form Authentication Example Conclusion Reference
introduction
Deploying secure distributed enterprise reporting solutions is a very challenging process. From reporting access to data sources that provide important data (sometimes sensitive data), you need to make decisions for your secure authentication and authorization for users in the report environment. In terms of security, the report is the weakest link in the report chain.
The required security type depends on the report environment and the installed security system type. Microsoft® Windows® Authentication is the main system for ensuring report security in Microsoft® SQL ServerTM 2000 Reporting Services. Windows Authentication provides tight integration with other Microsoft server products, because Reporting Services is designed and tested on Windows Authentication, so it is the highest in this environment.
However, in some cases, it may be necessary to expand the Reporting Services security system to meet the needs of enterprise custom security. You can achieve this with a rich Reporting Services API development platform. This guide will overview extensions in Reporting Services, especially security extensions. You can also download sample form authentication extensions for Reporting Services, and conduct in-depth research. Subsequently, you can use the Reporting Services security extension to add custom security to your business report solution.
Back to top
About this guide
The information provided in this guide is designed to:
• Introduce Reporting Services Security Extensions. • Determine to use custom authentication and authorized positions and methods in Reporting Services. • Introduce authentication and authorization in the Reporting Services. • Introduce Form authentication and its implementation. • Provide a form authentication example that can be downloaded and studied.
Prerequisite
This guide does not introduce ASP.NET security or form authentication, and has not provided deep knowledge about programming or application security. As a developer who is expected to implement security extensions for Reporting Services, you should have an in-depth understanding of one or more aspects:
• Microsoft Reporting Services feature, especially authentication, authorization, and role-based security. • Microsoft .NET Framework. • ASP.NET and ASP.NET security. • Form authentication. • .NET language development experience. This article only provides examples written in C #.
To directly understand the code, go to the Form Authentication Example section. However, you may find that the previous part is very helpful, and these parts describe some of the techniques you will use and how to use these technologies together.
Back to top
Reporting Services Platform
Deploy and deliver a report throughout the company through Reporting Services. From a developer's perspective, Reporting Services provides a variety of programming opportunities through the key development platform of .NET Framework and Web Service. Reporting Services can be deployed in a manner that can be used in any company, so that a comprehensive report solution can be provided in any company. However, the open and scalable programming architecture of Reporting Services make it no longer an off-the-shelf product, and more like developers and end users' report platforms. Expansion Reporting Services
Reporting Services has scalability. By hosting code API, you can develop, install and manage the extensions used by many Reporting Services components. You can create a dedicated or shared assembly using .NET Framework, add new Reporting Services to meet the growing business needs. Developers can extend Reporting Services in the following ways:
• Create other data processing extensions in addition to Reporting Services, Oracle and OLE DB providers, ORACLE and OLE DB providers. Data Processing Extensions can be used to read data from your own unique data source and can be used to enter other business logic when creating and filtering data sets. • Create additional delivery extensions in addition to Reporting Services currently included in the current email and file sharing delivery extensions. Delivery extensions can be used to deliver reports to devices such as fax machines, pager, printers. • Create other rendering extensions in addition to Reporting Services already included. • Create additional security extensions except for Windows Authentication extensions (it is currently the default security mechanism for this product).
As mentioned earlier, this guide mainly introduces how to verify the secure system of the Reporting Services through the form.
Safe expansion
With Reporting Services Security Extensions, you can authenticate and authorize the user or group, which makes different users can log in to the report server and perform different tasks or operations according to their identity. By default, Reporting Services uses Windows-based authentication extensions, which uses the Windows Account Protocol to verify the identity of users who have the system account. Reporting Services Authorize users using role-based security systems. The REPORTING Services-based security mode is similar to other technologically based roles. Since the security extension is based on an open, scalable API, new authentication and authorization extensions can be created in Reporting Services. The following is a typical example of using a form-based authentication and authorization security extension implementation:
Figure 1 is shown in the figure, identity verification and authorization are performed as follows:
1. The user attempts to access the Report Manager by entering the URL, and then redirected to a form that collects user credentials for the client application. 2. The user submits the credential to the form. 3. Submit the credentials of the user to the Reporting Services Web Service via the LogonUser method. 4. Web Service calls the security extension provided by the customer and verifies whether the username and password exists in the custom security agency. 5. When authentication, Web Service will create an authentication ticket (called "cookie"), manage the bill, and verify that the user's role can access the home page of Report Manager. 6. Web Service returns the cookie to the browser and displays the corresponding user interface in the Report Manager. 7. After the identity verification, the browser issues a request to the Report Manager while transmitting this cookie in the HTTP header. These requests are sent to respond to user operations in the Report Manager application. 8. This cookie operates along with the requested user operation to the Web Service together in the HTTP header. 9. Cookie will be verified, if it is valid, the report server returns the security descriptor and other information related to the request operation from the report server database. 10. If the cookie is valid, the report server will call secure extensions to check if the user has the right to perform a specific operation. 11. If the user has been authorized, the report server will perform the request, and return the control to the call. 12. After the user is authenticated, the URL access to the report server will use the same cookie. This cookie is transmitted in the HTTP header. 13. The user continues to request operation on the report server until the session ends. When is safety expansion
Microsoft recommends using Windows Authentication as much as possible. However, in both cases, use Reporting Services to customize authentication and authorization:
• Internet or Extranet applications are not used or unable to use a Windows account. • You have custom users and roles, and you need to provide a matching authorization program in Reporting Services.
Safety expansion API
The following table lists the secure extensions available interfaces and classes.
Interfaces or class description IAUTHENTICATIONExtension interface indicates authentication extensions in Reporting Services so that you can implement security extensions available for user authentication (using custom authentication schemes). The IAUTHORIZATIONEXTENSION interface represents an extension that can be used to extend the authorization feature of Reporting Services so that you can implement security extensions available to authorize users to perform operations. The IEXtension interface represents the extension in Reporting Services. The ACECOLLECTION class represents a collection of access control items that specify one or more access to the trust. The Access Control item of the ACESTRUCT class (user, group or computer) is used to specify that the trustee can perform an operation on the project in the report server database. The CatalogOperationsCollection class represents a collection of directory operations. The DataSourceOperationsCollection class represents a collection of data source operations. The FolderOperationsCollection class represents the folder operation collection. The OperationNames class contains the field name and corresponding value of the user who can perform the project in the Reporting Services. The ReportOperationsCollection class indicates the report of the report. The ResourceOperationsCollection class represents the resource set. For more information on the various interfaces and classes of the Security Expansion API, see the Reporting Services online series.
Authentication in Reporting Services
Authentication is the process of establishing user identity privileges. There are many ways to be used for user authentication. The most common way is to use a password. When implementing Form authentication, such implementation should be used: requesting a user to provide credentials (generally entered the login name and password to verify the user according to user storage (eg, database tables or profiles). If the credentials cannot be verified, the authentication process will fail, and the user will get an anonymous identity.
In Reporting Services, the Windows operating system handles user authentication by integrating security or explicit reception and verification through user credentials. Develop custom authentication in Reporting Services to support other authentication scenarios. To do this, security extension interface IAUTHENTINTENSITIONEXTENSITION can be used. All extensions are inherited in IEXtension, which is the basic interface for any extended extension of the report server deployment and use. IEXtension and IAUTHENTICATIONEXTension are members of Microsoft.ReportingServices.Interfaces named space.
The Logonuser method is the core of all authentication in the Reporting Services. It can be verified using it user credentials to the report server. The basic security extension implementation IAUThenticationExtension.logonuser containing custom authentication code. In the Form Authentication Example (described later in this guide), Logonuser performs authentication checks in accordance with custom user stores in the credentials provided and custom user stores in the database. In the form authentication example, it is similar to the following procedure:
In AuthenticationExtension.cs (Sample)
Public Bool logonuser (String Username, String Authority)
{
Return AuthenticationUtilities.VerifyPassword (username, password);
}
In Autnal Static Bool VerifyPassword in AuthenticationUtilities.cs (Sample Authentication Example),
String supportPassword)
{
Bool passwordmatch = false;
// Based on the user name from the database from the database.
/ / See "How to: Use DPAPI (Machine Store) from asp.net", "HOW TO:
// Use DPAPI (User Store) and "How TO:
// CREATE A DPAPI LIBRARY "to learn how to use
// DPAPI securely stores details of the connection string.
SqlConnection conn = new SQLCONNECTION
"Server = localhost;"
Integrated Security = SSPI; "
"Database = Useraccounts");
SQLCommand cmd = new sqlcommand ("lookupuser", conn;
cmd.commandtype = commandtype.storedProcedure;
SQLParameter Sqlparam = cmd.parameters.add ("@ username",
Sqldbtype.varchar,
255);
SQLParam.Value = supportusername;
Try
{
Cn.open ();
SqlDataReader Reader = cmd.executeReader ();
Reader.read (); // Jump to the only row
/ / Return output parameters from the returned data stream
String dbpasswordhash = reader.getstring (0);
String salt = reader.getstring (1);
Reader.Close ();
// Now use the user input SALT and password
/ / And they are connected in series.
String passwordandsalt = string.concat (SuppliedPassword, SALT);
/ / Now there is a hash operation
String hashedpasswordwordsalt =
FormsAuthentication.hashPasswordforstoringInfigfile (
Passwordandsalt,
"SHA1");
/ / Now verify them. Returns true if they are equal
PasswordMatch = hashedpaals (dbparswordhash);
}
Catch (Exception EX)
{
Throw New Exception ("Exception Verifying Password."
EXMESSAGE);
}
Finally
{
CONN.CLOSE ();
}
Return PasswordMatch;
}
Authentication process
The Reporting Services Web Service provides custom authentication so that the Report Manager and the report server can perform form authentication.
The Logonuser method for the Reporting Services Web Service is used to submit credentials to the report server for authentication. Web Service uses the HTTP header to pass authentication tickets (called "cookie") from the server to the client to respond to verified login requests. The following figure describes how to authenticate users to access Web Service when using a report server that is configured to use a custom authentication extension to deploy your application.
Figure 2 As shown in Figure 2, the authentication process is as follows:
1. Client application call Web Service method logonuser authenticates users. 2. Web Service calls secure extensions (specifically, refers to the LogonUser method for the class that implements IAUThenticationExtension). 3. Logonuser's implementation verifies usernames and passwords in user storage or security agencies. 4. After the authentication is successful, the Web Service will create a cookie and manage it for sessions. 5. The Web Service returns the authentication ticket to the call to the application via the HTTP header.
The Web Service will generate a cookie for subsequent requests after authenticating the user through security extensions. This cookie will not always be saved in custom security agencies due to the reporting server. The cookie returns from the Web Service method logonuser and is used for subsequent web service method calls and URL access.
Security: To avoid leaking cookies during the transmission, you should use the Secure Socket Layer (SSL) to securely transfer the cookie returned from the LogonUser.
If you access the report server through the URL access by URL, the Internet Information Service (IIS) and ASP.NET will automatically manage the transmission of authentication tickets. If you access the report server via the SOAP API, the actuation of the proxy class must contain additional support for authentication ticket management. For more information on using SOAP API and managing authentication tickets, see "Use Web Service to customize security" later.
Authentication in Reporting Services
Authorization refers to the process of determining whether to grant a request type for a certain identity (access to a given resource permission in the Report Server Database). Reporting Services uses role-based authorized architectures, ie, the user role based on the user role to access the authority of the given resource. The Reporting Services security extension includes an authorization component (once the user gets verified on the report server, the authorization component is used to grant user rights). When the user tries to access the system or report server item through the SOAP API and the execution of the system or report server item, the authorization is called. To do this, you can use a security extension interface IAUTHORIZATIONExtension. As mentioned earlier, all extensions are inherited in IEXtension, which is a deployed basic interface. IEXtension and IAUTHORIZENSITIONEXTension are members of Microsoft.ReportingServices.Interfaces namespace.
In authorization, the key to any custom security implementation is that the access check is performed in the method CheckAccess. Whenever the user tries to operate on the report server, CheckAccess will be called. The CheckAccess method will be overloaded for each type of operation. For folder operation, an example of access check is as follows:
/ / Overload for folder operation
Public Bool CheckAccess (String Username,
INTPTR USERTOKEN,
Byte [] SECDESC,
Folderoperation RequiredOperation)
{
// If the user is an administrator, unlimited access is allowed.
IF (username == m_adminusername)
Return True;
Acecollection acl = deserializeaCl (SECDESC);
Foreach (Acestruct Ace In ACL)
{
IF (username == ace.principalname)
{
FOREACH (Folderoperation Aclopertories in
Ace.FolderOperations)
{
IF (ACLOPERATION == RequiredOperation)
Return True;
}
}
}
Return False;
}
The report server calls the CheckAccess method by passing the name of the login user, the user token, the security descriptor and the request of the user. Here. You will check the security descriptor of the username and the appropriate permissions of the request, and then return True, indicating that the access is granted, or returns false, indicating that the access is rejected.
Safety descriptor
When setting an authorization policy for projects in the Report Server database, client applications (such as Report Manager) will submit user information and project security policies to security extensions. This security policy and user information are collectively referred to as security descriptors. The security descriptor contains the following information about the project in the report server database:
• Groups or users with certain operation permissions to the project. • Type of the project. • Control the random access control list of project access.
The safety descriptor is created by Web Service Method SetPolicies and SetSystemPolicies. For more information on these methods and Web Service, see the Reporting Services Book.
Authorization process
Reporting Services Authorization is controlled by the current security extension that is currently running on the server. Authorization is based on roles and is limited to the permissions and operations provided by the Reporting Services security architecture. The figure below illustrates how to authorize the user to perform an operation in the report server database.
Figure 3 shows in Figure 3, authorization is performed in the following order:
1. After authentication is complete, the client application issues a request to the report server via the Reporting Services Web Service method. Authentication Bills passed to the Report Server in the form of cookies in the HTTP header of each Web request. 2. Cookie will be verified before any access rights check. 3. After completing the authentication of the cookie, the report server will call GetUserInfo to grant the identity to the user. 4. Users try the Reporting Services Web Service. 5. Report server calls the CheckAccess method, 6. and then retrieve the security descriptor and passed it to CheckAccess custom security extension implementation. At this point, the user, group or computer compares the security descriptor of the access item and is granted permission to perform the request operation. 7. If the user gets an authorization, the Web Service will perform the operation and return to the calling application.
Back to top
Form authentication example
If you have not installed a form authentication example, download the Forms Authentication Sample Installer and run it on your computer to install the sample code.
About this example
Form authentication sample security extensions can be downloaded as part of this guide, which uses form authentication and SQL Server to provide custom security modes with Reporting Services. This example is for demonstration purposes only, and does not apply to the production environment, and has not been tested in the production environment. Microsoft does not provide technical support for this example. In some cases, this example demonstrates best practices (eg, create a one-way hash, password with SALT). In other cases, the best practice is avoided for simplicity. It should be noted that the setting and management of this example security extension often requires you to have administrator access on the report server computer. In any case, it is not recommended to use this example on the production server in the connection environment. If you have any questions about Reporting Services security extensions, contact your Microsoft Consulting Service (MCS), the main support service (PSS), or other Microsoft Support service representative.
Claim
To use this example, the following tools must be installed:
• The report server of Microsoft SQL Server 2000 Reporting Services is installed. • Used to access the Microsoft Internet Explorer 6.0 or higher of Report Manager. • Install the development of Microsoft® Visual Studio® .NET 2003.
Precautions
When you implement custom security extensions or use this example, please pay attention to the following:
• Report servers cannot be run under the mixing mode security system (for example, using Windows Authentication and Form authentication). This also applies to any ASP.NET application. • Be sure to save a backup copy of all configuration files that are changed by configuring this example. • Although it can be restored to Windows Authentication after deploying this example, this may have a certain difficulty. For more information, see "Delete Sample Extensions" later later in this guide. • Covering Windows Authentication is very dangerous. The report server has scalable in security, but only uses Windows Authentication to fully test and support it. • Always use the Secure Socket Layer (SSL) for Form authentication. • In this example, the user input is passed to the Transact-SQL command for authentication. In your own custom security extension (in conjunction with Form authentication and SQL Server), you should carefully input verification and make sure that the result command does not include a syntax error. Be sure to verify all user inputs to prevent malicious users causing an application to run any SQL command (also known as "SQL Insert Attack"). The username provided in the login process is especially important because the report server custom security mode is completely depends entirely on whether the user can correctly identify, authentication, and authorization. • In custom user storage, avoid user input with the following characters: • @ & = $, / *> <|. "/. User names with these characters may cause" My Reports " (My Report) The function has a problem, because the folder is created in the server, and these characters may cause a problem with the folder name and folder path. Sample code uses the regular expression to test the username if it is valid, and Make sure the path name does not exceed the maximum maximum path length. You should perform similar validation in the custom authentication code.
Form authentication
Form authentication is an ASP.NET authentication. With this authentication, unauthenticated users can be directed to the HTML form. When the user provides credentials, the system will issue cookies that contain authentication bills. In the subsequent request, the system first checks the cookie to determine if the report server has authenticated the user. The Reporting Services itself does not support form authentication. However, the security extension interface provided by the Reporting Services API can extend the Reporting Services to support the form authentication. If the Reporting Services extends to you can use the form, use the Security Socket Layer (SSL) to all communications communicated with the report server to prevent malware access to cookies for other users. SSL allows clients and report servers to authenticate each other and make sure other computers cannot read communication content between two computers. All data issued from the client via the SSL connection is encrypted, so that the malicious user cannot intercept the password or data sent to the reporting server.
Implementing Form authentication is usually to support non-Windows accounts and authentication. The graphical interface will be displayed to the user of the request to access the report server, and the credentials provided will be submitted to the security mechanism for authentication.
When there is an interactive user input credentials, the form authentication scheme will be used in the field. However, for unattended applications that communicate directly with Reporting Services Web Service, the form authentication must be used in combination with the custom authentication scheme.
In the following cases, the form authentication applies to Reporting Services:
• You need to store and authenticate users without Microsoft Windows accounts, and • You need to provide your own user interface form as a login page between the different pages of the Web site.
When writing a custom security extension that supports Form authentication, consider the following:
• If you use Form authentication, you must enable anonymous access on the Report Server virtual directory in the Internet Information Services (IIS). • The ASP.NET authentication must be set to "Forms". ASP.NET authentication can be configured in the web.config file of the report server. • Reporting Services You can authenticate and authorize users using Windows Authentication or custom authentication. Reporting Services does not support simultaneous use of multiple security extensions.
Deployment example
To run and check the code of the form authentication example, you must implement a few steps. After performing the installation and configuration steps, you can use or debug examples on the report server, or view the sample code in the Visual Studio .NET.
Compile and install extension assemblies
You must compile and install the extension by following these steps. These steps assume that you have installed Reporting Services to the default location: C: / Program Files / Microsoft SQL Server / MSSQL / Reporting Services. This location is collectively referred to as
Compile examples using Visual Studio .NET
1. Open CustomSecurity.sln in Microsoft Visual Studio .NET 2003. If you have downloaded the source code and install the sample to the default location, you can access it in C: / Program Files / Microsoft SQL Server / MSSQL / Reporting Services / Samples / Extensions. 2. In the Solution Explorer, select the CustomSecurity project. 3. On the Project menu, click Add Reference. 4. The Add Reference dialog will open. 5. Click the ".NET" tab. 6. Click "Browse" to make navigation to find Microsoft.ReportingServices.Interfaces on your local drive. By default, this assembly is in the
Applying assembles and login page authentication applications for Report, you need to make some modifications to Report Server and Report Manager profiles.
Key points: Back up all profiles before making any changes.
Modify RSReportServer.config file
1. Use Visual Studio .NET or a simple text editor (for example, Notepad), open the RSReportServer.config file. RSREPORTSERVER.CONFIG is in the
TYPE = "Microsoft.Samples.ReportingServices.customSecurity.authorization, Microsoft.Samples.ReportingServices.customSecurity "> Modify RSWebApplication.config file 1. Then you need to open the Report Manager profile rsWebApplication.config in the Security: If you run sample extensions in the development environment where the SSL certificate is not installed, the value of the Adding an extended security policy You will need to add code groups to custom security extensions to grant fulltrust permissions to the extension. To do this, you can add the code group to the rssrvpolicy.config file in the Class = "unioncodegroup" Version = "1" PermissionssetName = "FullTrust"> Class = "UrlmembershipCondition" Version = "1" URL = "$ CODEGEN $ / *" /> Class = "unioncodegroup" Version = "1" Name = "securityextensioncodegroup" Description = "Example Security Extension Code Group" PermissionssetName = "FullTrust"> Class = "UrlmembershipCondition" Version = "1" URL = "C: / Program Files / Microsoft SQL Server / MSSQL / Reporting Services / ReportServer / Bin / Microsoft.Samples.ReportingServices.customSecurity.dll" /> Note: For simplicity, the form name is not very strict, and the URL member identity item required in the security policy file is also simple. In the production safety extension implementation, a strong name assembly should be created and a strong name member identity condition is used when adding an assembly security policy. For more information on strong name assembly, see "Creating and use strong-name assemblies" on MSDN, whose URL is http://msdn.microsoft.com/library/en-us/cpguide/html/cpconworkingwithstrongly-namedassemblies .asp (English). Then, you need to add permissions for MyComputer code groups in the Report Manager policy file in the Class = "firstmatchcodegroup" Version = "1" PermissionssetName = "fulltrust" Description = "This code group grants Execution for MyComputer code Permission. "> Class = "zonemembershipcondition" Version = "1" Zone = "mycomputer" /> Configure web.config files To use Form authentication, you need to modify the Web.config file for Report Manager and Report Server to change your authentication and disable the simulation. Modify the Web.config file of Report Server 1. Open the web.config file in the text editor. By default, this file is in the 3. Find PATH = "/"> 5. Add the following This refuses to grant the permissions of the Report Server to unused users. Modify the Web.config file of Report Manager 1. Open the Web.config of Report Manager. It is located in the Configuring anonymous authentication By default, Windows User Group Guests contains a IUSR_Computername account. This account is used for initial local login and views the Logon.aspx page. To support form authentication, you must enable anonymous access to the ReportServer virtual directory. By default, anonymous access is disabled. Enable anonymous authentication 1. In "Internet Information Services", select the ReportServer virtual directory (usually a member of the default website), then open its property tab. 2. Click the Directory Security tab. 3. On the Anonymous Access and Authentication Control section, click Edit. The Authentication Method dialog is displayed. 4. Check the Anonymous Access check box. 5. Click OK. 6. Repeat the above steps on the Reports virtual directory. Create a user account database The example contains a database script, which is CreateUserstore.sql, which is used to create a user storage for the form example in the SQL Server database. Create a useeraccounts database 1. Open "Query Analyzer" and then connect to the local instance of SQL Server. 2. Find the SQL script file CreateUserstore.sql. This script file is included in the sample project file. Note that at the end of the script, "localmachine" must be replaced with your own computer name. For Windows 2003 users, replace localmachine / aspnet (except for IIS 5 compatibility mode) with NT Authority / Network Service (except for IIS 5 compatibility mode) 3. Run the query to create a UserAccounts database. 4. Exit "Query Analyzer". Test example Test example extension by the following steps. Registered administrator users, adding the username, password Haxi and SALT value to the user table in the UserAccounts database. It will also ask you to enter this username in the Report Server profile. You will then log in as the same user to ensure that the report server runs the password verification routine and properly load the extension assembly. Test example security extension deployment 1. Run IisreSet.exe at the command prompt, restart IIS. 2. Open Report Manager. You can open it from the Reporting Services program menu or open it by accessing the Reports virtual directory from the browser. 3. Enter the username and password, then click Register User to add the user to the account database. 4. Open the RSReportServer.config file. Find the TYPE = "Microsoft.Samples.ReportingServices.customSecurity.authorization, Microsoft.Samples.ReportingServices.customSecurity "> 5. Return to the UILogon.aspx page, re-enter the username and password, and then click Login. You should be able to access the Report Manager and the Report Server unrestricted. The created administrator user is the same as the permissions of the report server with the permissions of the built-in administrator account on the local computer. In this example, only one user can specify as an administrator. After you have a built-in administrator account, you can register other users and assign them in the role in the report server. Note: It is recommended to add an administrator user to the official System Administrator and Content Manager roles of the report server. This prevents an empty security descriptor in the report server database. For more information on the SYSTEM Administrator and Content Manager roles, see the Reporting Services online series. Use Web Service to customize security You can use the Web Service API for form authentication, just like the Windows Authentication is the same as the form authentication. However, you must call the logonuser in the Web Service code and pass the current user's credentials. In addition, the Web Service client will not have an automatic cookie management feature provided by Internet Explorer or other web browser. You must extend the ReportingService proxy class to include cookie management. To do this, you can cover the GetWebRequest and GetWebResponse methods of the Web Service class. For examples of this, see "ReportingService.logonUser Method" on MSDN, whose URL is http://msdn.microsoft.com/library/en-us/rsprog/htm/rsp_ref_soapapi_service_lz_3d7q.asp (English). Debug sample extension Running sample extensions in debugging programs can not only help you solve trouble questions, but allow you to effectively browse the code and view the running report server authentication and authorization process. Microsoft .NET Framework offers a number of debugging tools that help you analyze sample code. The effect of the tool depends on the task you try to complete. In this guide, the selected debugging tool is Visual Studio .NET 2003. DebugForm authentication sample code 1. Make sure to deploy the example as follows. 2. Start Visual Studio .NET 2003 and open CustomSecurity.sln on the test report server. 3. Open Internet Explorer and navigate to Report Manager while keeping the sample code in Visual Studio. 4. Navigate to Visual Studio and custom security extensions and set some breakpoints in your code. 5. When the extension project is still an active window, click Process on the Debug menu. The Process dialog will open. 6. From the list of processes, select the ASPNET_WP.EXE process (if your application is deployed on IIS 6.0, select W3WP.exe), and then click Additional. When the "attached to the process" dialog opens, make sure that the program type "Public Language Runture" is selected, and then click OK. To improve debugging performance, make sure that the program type "native" is not selected. 7. Now, enter the user credentials in the login form, and then click Login. If you encounter a code corresponding to the breakpoint, the debugger will stop execution at the first breakpoint. 8. Use the F11 key to browse the code. For more information on using Visual Studio for debugging, see the Visual Studio .NET documentation. Note: In this way, commissioning requires a lot of resources and processor times. If you encounter problems, close Visual Studio, reset IIS, and then restart by attaching the CustomSecurity solution to the ASP.NET work process and log in to Report Manager. Delete sample extension Although it is often not recommended, it is still possible to return to Windows Authentication after deleting examples. To restore Windows security, do the following: • Restore the following files from the backup copy: Web.config, RSReportServer.config and RSWebApplication.config. This will set the identity verification and authorization method of the report server to the default Windows security. This will also delete the content you entered in the Report Server or Report Manager configuration file. • Disable anonymous access to the Report Server Virtual Directory in the Internet Information Server (IIS). After deleting configuration information, security extensions will not be available for reporting servers. You don't have to delete any security descriptors created when running the report server under the sample security extension. When you enable Windows Authentication, the Report Server automatically assigns the System Administrator role to the Builtin / Administrators group on your computer hosting. However, you must use any role-based security to Windows users. Typically, after migrating to different security extensions, it is recommended that you do not return to Windows Authentication. Otherwise, when you try to access items in the Report Server, if they have a custom security descriptor without a Windows Authentication security descriptor, it may encounter an error. Back to top in conclusion Microsoft SQL Server 2000 Reporting Services is an extensible report platform that can be used for business report development and deployment. Reporting Services contains a Windows Authentication module that uses the Windows account to ensure the security of the report server, but in some cases, you may need to support different security modules. To this end, the Reporting Services contains a set of secure extension APIs that create custom security extensions. In the example provided, you have learned how to implement custom security by form authentication. Microsoft is committed to providing secure demand in the enterprise by providing secure scalability in Reporting Services and subsequent versions. As a developer, you should be aware of the risk of custom security extensions, and should be careful consideration to properly implement and apply the security system used by the report server. Back to top Reference For more information, see the following resources on the MSDN: • How to: Use Forms Authentication with SQL Server 2000 (English) • USING ROLE-BASED Security (English) • Microsoft.ReportingServices.Interfaces Namespace All version
