hmm this week, I spend 2 days reading the code, 2 days modifying and coding new extensions - added password recovery, emailing users abt the link to change password and a different register page.
Finally, I completed it.
There are some pitfalls I encountered:
1. In the ReportServer folder, the logon.aspx "Codefile=" should be changed to "CodeBehind" after deployed to the server.
2. In C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services, the rsreportserver.config file must be properly configured or else the SQL reporting services will not start!! The WebServiceAccount in the below settings must be "computername" followed by the ASPNET. This is the asp.net worker process account.
<PolicyLevel>rssrvpolicy.config</PolicyLevel>
<WebServiceAccount>"COMPUTERNAME"\ASPNET</WebServiceAccount>
<IsWebServiceEnabled>True</IsWebServiceEnabled>
3. For further info, follow the html file instructions under
C:\Program Files\Microsoft SQL Server\90\Samples\Reporting Services\Extension Samples\FormsAuthentication Sample
Resources which I used:
http://msdn2.microsoft.com/en-us/library/aa902691(SQL.80).aspx
http://support.microsoft.com/kb/907267
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconformsauthenticationacrossapplications.asp
http://www.codeproject.com/aspnet/smtp_mail.asp
My R&D notes on which methods to use:
Method 1: Using Reporting services security extensions
It will be using SSL and form authentication. Some parts of the authentication may need to use the reporting services web service call. Authetication is made possible through the IAuthetication Extension. A method called LogonUser passes user credentials (Username and Password) to a report server for validation against the database. LogonUser is the web service method of the security extension. Upon successful authentication, it will create a cookie and manages it for the session. The authentication ticket in the form of a cookie will be returned to the calling application on the HTTP header. Once authenticated, requests are made to the report server through the reporting services web service methods. Once the cookie is validated, the report server calls GetUserInfo and the user has an identity. Authorization is role-based and limited to the permission and operations supplied by the Reporting services security architecture. When the user attempts an operation through the reporting service web service, the report server will call the Authorization Extension which will use the access check in the CheckAccess method to check for appropriate access in folder, data source, resource and catalog operations. The parameters passed into the CheckAccess method are the name of the logged-on user, user token, security descriptor and the requested operation.
Ponits to note:
1. Users cannot use names with the following characters – : , ?, ; , @, &, =, +, $, \, *, >, <, |, . , “ and /
2. SSL is needed for all communications with the report server to prevent malicious users from stealing another user’s cookie. In an SSL connection, the data is encrypted so that users cannot intercept password or sniff the data sent to the reporting server.
3. The report server can only run under 1 security system – either Windows or Forms authentication.
4. Validation of user inputs is important to prevent SQL injection attacks.
5. Have to add the Report Server Web site to the Trusted Sites Zone or the authentication cookie can’t get through. 6. Both the Report Server and the web application for login are required to be in the same domain as IE doesn’t permit cross-domain cookies.
Method 2: Using dot net built-in forms authentication with reporting services
This method re-uses dot net framework 2.0 user database and controls. The connection string for membership has to be placed in the machine.config. Furthermore, both SSRS and the web application need to share cookies so both web.config files for both the web app and SSRS have to be identical under the and . Estimation: unknown because a lot of testing need to be done as there are not very many documentation on this method. May have some hiccups in integration. The machine.config is unique to each machine. Changes in there may pose some problems in maintence later on. But effort to make this to work may be small. Subscription delivery of reports may not work under this method.