This page describes how service providers and/or implementers can run SQL Server Web Tools as well as how they can customize the application to provide branding and better fit within their account management procedures.

Security management

Full Trust
SQL Server Web Tools runs in Full Trust mode. In a hosted environment, SSWT should either be implemented on a dedicated server, or in it's own application pool.
Credentials
There are 2 places where the application prompts for security credentials. The first is to login into the portal and the second is to log into a specific database server. You can use SSL to help protect these entry point pages from possible exploit.
Connections
Because of the way that SMO connects to SQL Server, the web application needs to keep the connection information around so that a new SMO object can be constructed on each request. To keep this information from being attacked, the application encrypts this information in memory just in case this information shows up in a stack trace or a dump file. This information is not sent over the wire for the same reason of keeping this information away from prying eyes.

Customization

SQL Server Web Tools takes advantage of a lot of features that are new to ASP.NET 2.0. Instead of going into great detail on these new features, which are already well documented online, this document will go into detail on how these new ASP.NET 2.0 features are leveraged within the SQL Server Web Tools, and how an implementer would customize these technologies to suit their needs.

There are 3 major components in SQL Server Web Tools that lend themselves to being customized. These components are Site Urls, Theme Support, and Membership Providers.
Site Urls
Site Urls are stored in the web.sitemap file that is located in the web application’s root directory. This sitemap file lists the different pages that comprise the application and how those pages are logically organized. For example, to access the TableProperties page, you must first select a Table from the Tables page. Contextual information is passed from the Tables web page to the TableProperties web page when a table is selected from the Tables web page.

The sitemap also defines which roles are allowed to access the individual pages that make up the application. By using a technique called Security Trimming, navigate nodes are removed from the SiteMap which the user doesn’t have permission to access. All of the navigation controls within the application use the SiteMap and its nodes to provide links to the different pages. This makes it very easy to configure which pages a user can see by defining new roles and adding/removing a user from these roles.

A new property to the SiteMap is the showAsTask property. This property is used by the TasksBox control to provide the user with common tasks based on the contextual page the user is on. Not all nodes within the SiteMap would qualify as a “task”. For the ones that do qualify, the value of showAsTask is set to true for the node to show up inside a TasksBox control.

Another new property added to the SiteMap is the queryStringKeys attribute. This attribute is used by the application to build URLs to the respective page and to ensure that all the contextual information is passed in the URL. For example, the TableProperties.aspx page needs to know the database, schema and table values for it to find the SMO Table object in the database.

For more information on Site Urls and/or SiteMaps, please refer to these online articles:
Themes
Themes provide a way for you to change the colors used in the application, and allow the user to choose the theme that he/she would like to use.

Themes are stored in the AppThemes directory in the web site. Each new theme should be created in a different directory under the AppThemes directory. SQL Server Web Tools only ships with one theme, which is known as the “default” theme.

All the controls are written in such a way as to pull theme information from the user’s chosen theme. Each theme would need to include the default stylesheet (default.css) and the default skin file (default.skin). Images for a theme are stored in the images subdirectory under the theme directory. The controls that emit image tags use relative paths to resolve the image to the image file in the user’s theme directory. As such, since the controls only know about certain images, you have to use the same image names as the controls expect. You can use other image names for images that exist only in your stylesheet.

For more information on theme support in ASP.NET 2.0, please refer to these articles:
Providers
SQL Server Web Tools uses the Membership, Role and Profile providers that come with ASP.NET to provide the framework to support the portal aspect of the web application. The portal aspect of the application encompasses all of the web parts, which allows the user to choose what web parts they would like to display on their home page.
Membership Provider
SQL Server Web Tools uses the SqlMembershipProvider that comes with ASP.NET 2.0. This provider uses tables stored in a special (aspnetdb) database on a SQL Server. If you want to use a different membership provider you can use the ActiveDirectoryMembershipProvider that comes with ASP.NET. Or, by using the MembershipProvider base class, you can write your own provider to provide for authentication used by the SQL Server Web Tools portal. The authentication used here is only used by the portal part of the SQL Server Web Tools web application and is not used by the actual SQL Server management within the web application. The management part of the application uses the user’s actual SQL login to control access to specific databases and schemas within that database.

In future versions of the tool there may be a new membership and role provider that actually makes use of the users true SQL credentials to authenticate their membership and uses the SQL Server database roles to determine what roles the user is a member of.
Role Provider
The web application uses the SqlRoleProvider that comes with ASP.NET 2.0. This provider uses tables stored in a special database (aspnetdb) to map a MembershipUser to certain Roles. These roles are used by the web application to control what links the user has access to, and to modify the UI of the application based on their role membership.

If you would like to use another Role Provider you can use the ActiveDirectoryRoleProvider that comes with ASP.NET 2.0. If you would like to use another store to manage your roles, you can write your own provider by extending the RoleProvider base class that comes with ASP.NET 2.0.

For more information on Membership and Role Providers, please see the following:

Last edited Jun 15, 2006 at 3:25 PM by edlehman, version 4

Comments

No comments yet.