Like the RS Windows-based authentication (by default, when Reporting Service 2005 first installed, it uses Windows Authentication mode), RS Forms Authentication security extension provides the necessary infrastructure for user authentication and authorization.
- User authentication: During the authentication stage, the custom security extension determines the user’s identity by obtaining it from a trusted authority - by querying the user profile store. A successful outcome of this phase is an authentication ticket in a form of a session cookie sent to the client.
- User authorization: Authorization occurs after authentication and determines what the user can do. For example, if the user has submitted a report request, during the authorization phase your custom security extension must verify if the user has indeed rights to do so. Typically, to simplify the security maintenance effort, the report administrator will use the Report Manager to create role-based security policies just as she/he would if Windows-based authentication is used.
Figure 1 depicts an overview of how the RS custom security extension works. It also shows sequence flow between the client and the report server, configured to use a custom security extension.
User Authentication
1. The client application (DotnetNuke) displays a logon form to prompt the user for credentials, (user name and password). If a user has not been authenticate, he will be redirected to the login form automatically.
2. Once the user credentials are collected, the application invokes the LogonUser RS Web method to log the user to reporting services.
3. Next, the report server asks the custom security extension to authenticate the user by calling its implementation of IAuthenticationExtension.LogonUser. How the custom security extension does this is of no concern to the report server.
4. If the user is successfully authenticated, the LogonUser SOAP API call retruns a ticket in the form of a session cookie which the report server expects to find in subsequence calls from the client. When a browser is used as a client, the session cookie will be automatically passed back with all subsequent requests. When other types of clients are used, you will need to take an extra step to pass the cookie implicitly with the call to the report server.
User Authorization
1. The client submits a report request wither by URL or SOAP
2. The report server asks the custom security extension to authorize the user request by calling the appropriate IAuthorizationExtension.CheckAccess overload method.
3. If the request is successfully authorized, the report server generates the report and sends it back to the client
Although the scenario depicted in figure 1 specifically refers to requesting reports, any type of action against the report catalog will be subject to custom authorization checks. For example, if the client is the report manager, each time the user initiates a new action from the portal, the report server will call down to the custom extension to authorize the request.