Visual InterDev
The World Wide Web and HTTP provide the largest imaginable audience for Web applications and a proportionately increased need for security. In addition, Web development teams can now span the globe. To control just how that audience and team work with Web application files and gain access to the system that supports them requires security.
Security for Web applications is a complicated subject because it can be set at several levels in several different ways. The choices depend on the system and servers used and the needs of the Web application.
Some of the considerations are:
Locations for Setting Security
User Authentication
Permitting Access to Web Applications, Folders, and Files
Guidelines for Design-Time Security
Guidelines for Run-Time Security
Securing HTTP Transmissions (SSL)
Administration and Maintenance Considerations
For more information about security, see in the MSDN Technical Articles section or see the Microsoft Security Advisor Web site at https://www.microsoft.com/security.
Locations for Setting Security
You can set security options in several locations depending on your system and the assumptions you can make about your visitors. For example, basic security for an intranet can be handled and maintained in parallel with the security for the network itself. For an Internet Web application, you can add security through the pages provided to the Web browser using the Web application.
The following table shows a summary of many options you have for security locations. As you can see, you may need to use several interfaces to get the results you want. This table assumes you are using Microsoft® Windows NT® with Microsoft® Internet Information Server for your Web services and Microsoft® SQL Server® for your database server.
| Location | Example interface |
| Operating system | User accounts specified in Windows NT(1) User Manager |
| Folder | Sharing properties set in the Windows NT Explorer |
| Web server | User accounts and server properties set in Internet Information Server Administrator |
| Virtual root | Internet Information Server Administrator |
| Database | Permissions specified in SQL Server, Enterprise Manager |
| Web application | Web application properties set in Visual InterDev Web Permissions and stored in a session |
| Page | Server script written in Visual InterDev, Source Code Editor |
| Source control | User accounts and permissions specified in Visual SourceSafe Administrator |
(1) Applies only to Web servers on Microsoft Windows NT with NTFS file system. NTFS allows you to specify per-file Access Control Lists (ACLs). Use of the FAT file system, whether on a Microsoft® Windows® 95 or Windows NT server, greatly reduces the security features available.
For all interactions with your Web server, Visual InterDev uses the Microsoft® FrontPage® server extensions that may use the existing security features of your operating system and Web server. For example, the extensions are integrated with Windows NT and Internet Information Server to manage Web application security. You interact with the FrontPage extensions through the Visual InterDev user interface.
Visual InterDev and security components
.gif)
When planning which security options to use for your Web application and where you want to set those options, it is helpful to consider four types of access to your site. You may want to:
Allow any Web visitor to execute ASP pages and read HTML pages at run time.
Restrict access to registered Web visitors at run time.
Allow Web developers and authors to write to your files at design time.
Restrict Web administration to certain authorized users.
For a complete understanding of security options affecting your Web application, read about the security features of the FrontPage server extensions, Internet Information Server, and Windows NT. If you use a database in your Web application, you might want to become familiar with the security models of ODBC databases, such as Microsoft® Access or SQL Server®. For more information about setting security options for Windows NT and Internet Information Server, see the documentation for those products.
User Authentication
In Web security, your central concerns are identifying a user and controlling the user's access to your Web application and its resources. You accomplish this by implementing measures to authenticate users and specify access permissions.
In choosing your security options, you need to specify how the user provides an identification to your Web application, how that identity is verified, and what level of access or permissions that user is allowed. The following table provides guidelines to help you choose the appropriate options for your Web application.
| Location | Example interface |
| Operating system | Domain and user account specified in Windows NT |
| Web server | User accounts and server properties set in Internet Information Server Administrator |
| Database | Permissions specified in SQL Server, Enterprise Manager |
| Web application | Web application properties set in Visual InterDev Web Permissions dialog box, login pages, and variables stored in a session |
Each of these locations provides a different feature set for implementing user identification, verification, and permission levels. Depending on the systems and software you are using, the feature sets may work together to set options at the operating system level or they may change related options at other levels. For example, if you set permissions on a file or folder in the Visual InterDev Web Permissions dialog box, you are also setting the permissions in Windows NT.
Operating System Level
Security choices you make for the operating system depend on the features and options your operating system offers. For example, if you are using Windows NT, you can implement authentication for a large number of people without explicitly specifying user accounts by using a special user account, referred to as the "guest user." This account is set up by default. If you want to distinguish between individual users and track them, you need to implement security options at a different level than your operating system.
In addition to authentication, the file system used by your operating system also affects the permissions you are able to grant to the user. For example, Windows NT may use either Window NT File System (NTFS) or File Allocation Table (FAT). NTFS allows you to specify an Access Control List (ACL) for files and folders so you can control access more granularly. FAT, on the other hand, does not provide the ability to specify lists and offers less control.
Web Server Level
Once the operating system has verified the identity of the user, the Web server can also evaluate the user's identity. The Web server primarily controls access at run time. For example, if you are using the default configuration for Internet Information Server, the Web server processes anonymous requests as the anonymous Internet Information Server user, IUSR_<machinename>.
The anonymous user set up by Internet Information Server is similar to an Internet guest account defined in Windows NT User Manager. However, password changes are not handled automatically. Changes to passwords for one requires an explicit change to the other.
If you have set the anonymous account to allow access to the requested file, Internet Information Server allows access to the file and satisfies the request. Otherwise, Internet Information Server rejects the request, returns an error to the client and informs the client of the authentication methods that Internet Information Server supports.
For more information, see the security topics in the documentation for the Web server you are using.
Database Level
Visual InterDev allows you to connect to a wide variety of data sources. The security measures you set for your database depend on the database management system you are using. The following paragraphs provide a few tips for setting security on databases used in Web applications. For the most recent information about setting security for your database, see the security topics in your database management system’s documentation.
For file-based systems such as .mdb files in Microsoft® Access, you can control security through the sharing permissions available on the folders and files for the operating system. If you are using SQL Server, you can use the features for granting and revoking privileges offered within the database management system. For example, Microsoft® SQL Server™ has a Security Manager that allows you to specify the privileges available to a single user or a group of users.
Although SQL Server for Windows NT offers three types of login security, the standard security choice is recommended. Standard login security requires a login ID and a password to access the server. Your Web application provides this information through the data connection and your users do not need to provide any additional identification.
While not recommended for all systems, some Web applications might use integrated security. If you choose to use integrated security, keep in mind that SQL Server will use Windows NT security to authenticate users so the Web application and database must reside on the same server. Windows NT does not delegate security to another server.
Web Application Level
In your Web application, you can take advantage of the security features provided through FrontPage server extensions and through the Global.asa file processing available with Active Server Pages.
FrontPage Server Extensions
Visual InterDev works through the FrontPage server extensions to provide the ability to manage design-time Web permissions using the underlying security model of the host operating system on the master Web server.
If your operating system is Windows NT with the NTFS file system, the FrontPage extensions manage access for administrators and authors using file ACLs for the DLLs in the following table. These directories are hidden to the Web server but available to the file system:
| Function | DLL | Location |
| Administrative (i.e., setting Web permissions) | Admin.dll | <Webdir>/_vti_bin/_vti_adm |
| Authoring (i.e., opening a file) | Author.dll | <Webdir>/_vti_bin/_vti_aut |
| Browsing (i.e., viewing links) | Dvwssr.dll | <Webdir>/_vti_bin/_vti_aut |
When you perform a function, such as changing permissions on a Web application, your request is sent over HTTP at the server and routed to one of these ISAPI DLLs. For example, a request to perform an administrative function is handled by that Web application's Admin.dll. In the request, the client provides credentials that identify the user who is logged in to the client workstation. This user must have read permission (equivalent to read and execute individual permissions) for the DLL handling the request; otherwise, the request is denied.
Thus FrontPage restricts who may perform a given request by controlling read permission on the DLLs in _vti_bin. Whenever a change is made to a Web application's permissions via the Web Permissions dialog box, the FrontPage extensions on the server modify the ACLs on the DLL's _vti_adm and _vti_aut directories in that Web application's _vti_bin directory accordingly.
Note FrontPage does not change ACLs on content files to manage design-time security; it only changes ACLs on the directories that contain the gatekeeper files admin.dll, author.dll, and dvwssr.dll. FrontPage manipulates content file ACLs to manage run-time security, which is the topic of the next section.
Global.asa File Processing
Visual InterDev supports Web applications that make full use of Active Server Pages. One of the features of an Active Server Page is the automatic processing of a Web application's Global.asa file, if present, at the start of a new session with that Web application. You can use the Web application and session to control access and processing of your Web application. The user never actually sees the Global.asa file and the security provisions you add to it.
Permitting Access to Web Applications, Folders, and Files
After specifying a way of identifying users, you can control access to your system resources through setting permissions. Typically, you set permissions based on files and directories.
At the operating system level, you can set permissions for individual user to read, write, execute, delete, change permissions on, or take ownership of a file.
In addition, Windows NT defines some standard permissions that combine one or more individual permissions. It is these standard permissions that are usually assigned to files or directories. For instance, having change permission is equivalent to having read, write, execute, and delete individual permissions. Having full control is equivalent to having all the individual permissions. Having the standard read permission is equivalent to having individual read and execute permissions.
In this document, standard permissions are used unless otherwise noted.
Controlling User Access to Resources with ACLs
Identity and permissions together determine a user's access to resources. The entire set of permissions assigned to a resource, for example, a file or directory, is called an Access Control List (ACL). When a user attempts to access a resource, the operating system checks the ACL of the resource to verify that the user has the proper permissions for the type of access being attempted. For instance, if a user who has read-only permission on a file attempts to delete that file, that user is denied access and cannot delete the file.
Here is a simple example. A Web site manager wants to use security to protect a single file on the site, say Sample.htm, from being read by users browsing the site anonymously. By simply changing the permissions on Sample.htm so that the anonymous user account does not have read permissions for the file, anonymous users will not be able to view Sample.htm.
Note The permissions you set for the Windows NT group, "Everyone," also includes the anonymous user.
Visual InterDev Web Applications
Visual InterDev exposes the security model defined by FrontPage for Webs hosted on a server running the FrontPage server extensions. This model is summarized here, and described in more detail in "Using the FrontPage® 97 Server Extensions with the Microsoft Internet Information Server" in the FrontPage documentation. It extends to Web applications the permissions model discussed above for files and directories.
Levels of Web Access
FrontPage server extensions define three levels of access for a Web application. An individual user, or an entire group of users, is either assigned one of these three levels or has no access. Access is defined on a per-Web application basis. The operation of defining access on a Web is referred to as "setting Web permissions." The three levels of access are administer, author, and browse. These are described below.
| Access level | Permission to |
| Administer |
|
| Author |
|
| Browse |
|
Guidelines for Design-Time Security
Design-time security is managed by controlling which users and groups of users are granted administer and author access to Web applications.
To give a user full design-time access to a Web application, the user should be granted administer access to that Web application. If you want a user to be able to create new Web applications on a server, the user needs administer privileges on the root Web of that server. To give a user enough access to fully modify an existing Web application, but not to delete it, the user should be granted author access to the Web application.
During design time, you might need to provide various levels of access to members of your Web development team. Not all members need administrative privileges. Some members may need only write access to certain folders or directories. By default, Web applications inherit the same rights that the root had at the time the Web application was first created. For more information about specifying privileges for design time, see Setting Web Application Permissions.
Controlling Developer Access to your Development Web Application
If you want to control the privileges that members of your Web team have for changing your Web application files, you can use Visual InterDev along with settings at other locations. You can use the following tables to help you choose security settings that are appropriate for your Web applications.
| Location for setting | Typical Intranet setting |
| Operating system | Windows NT Challenge/Response (NTLM) |
| Windows Explorer folder (OS) | Add user group or individuals to permissions list |
| Web server | Server-specific |
| Database | In the Enterprise Manager, set security type to Standard |
| Visual InterDev Web project | Add user to Visual InterDev Web Permissions list |
| Visual SourceSafe | Add users to Visual SourceSafe Administrator |
The following table shows typical settings for security on the Internet.
| Location for setting | Typical Internet setting |
| Operating system | Basic clear text |
| Windows Explorer folder (OS) | Add user group or individuals to permissions list |
| Web server | Same as operating system |
| Database | In the Enterprise Manager, set security type to Standard |
| Visual InterDev Web project | Add user to Visual InterDev Web Permissions list |
| Visual SourceSafe | Add users to Visual SourceSafe Administrator |
Specifying Web Administrators
When you first install your Web server, you are prompted to supply a Web administrator password. You can specify that other users have the same administrator privileges for your Web applications. For example, you might want someone else to add new users or change Web permissions.
You can use the following table to help you choose what security options are appropriate for your Web applications.
| Location for setting | Typical Intranet setting |
| Operating system (Windows NT) | Windows NT Challenge/Response(NTLM) |
| Windows Explorer folder (OS) | Add user group or individuals to permissions list |
| Web server | User groups and password settings must match the operating system |
| Database | In Enterprise Manager, provide appropriate database permissions |
| Web application | Global.asa file |
| Visual InterDev Web project | Add user to Visual InterDev Web Permissions list |
This table shows typical settings for the Internet.
| Location for setting | Typical Internet setting |
| Operating system (Windows NT) | Basic clear text |
| Windows Explorer folder (OS) | Add user group or individuals to permissions list |
| Web server | Allow Anonymous |
| Database | Provide TCP/IP access and special .dll In Enterprise Manager, provide appropriate database permissions |
| Web application | Global.asa file |
| Visual InterDev Web project | Add user to Visual InterDev Web Permissions list |
Using Source Control
Applying source control to your Web application during development is another way you can add security during design time. Visual SourceSafe added to your Web server helps control who can check out and modify files in the Web application.
Guidelines for Run-Time Security
After a default installation of Microsoft Internet Information Server and FrontPage server extensions, Web applications on a FrontPage server may be read anonymously by any browser that can make an HTTP request to the server. To secure their Web applications from such unrestricted access, Visual InterDev authors use run-time security.
As part of the development process, authors routinely test their Web applications by using a Web browser of their choice to read their Web pages. For this reason authors must be aware of run-time security considerations even while authoring.
Note If you use the same Web server for production as you do for development and testing, then the run-time security becomes the same as production security. However, if a Web application is put into production on a different server, the security settings on the production server should be reviewed and adjusted as necessary.
For example, if the production server has FrontPage extensions and the Web application was transferred to the production server using the Copy Web command, security settings need to be reestablished through Visual InterDev. If the production server is an Internet Information Server without FrontPage extensions, then the security should be established using Windows Explorer to manage file and directory ACLs on the Web applications content.
Run-time security is managed, first, by controlling whether all users or only registered users are permitted to browse a Web application, and, second, by controlling which users are granted browse access to those Web applications that only permit registered browsers.
Browsing Permissions
The FrontPage security model facilitates the use of two access levels for end users: unrestricted browsing and restricted browsing.
Unrestricted Browsing
Unrestricted browsing is the default setting for new Web applications. All users may read (browse) the content of a Web application that permits unrestricted browsing. End-user requests to read Web pages are satisfied anonymously; that is, end users are not required to identify themselves before fetching pages.
Note Because end-users are never required to identify themselves, it makes no difference whether they have browse access to the Web application. For an explanation of how the unrestricted browsing state is implemented using the Allow Anonymous setting of Internet Information Server, see Run-Time Security Considerations, below.
Restricted Browsing
Using the Web Permissions dialog box, any root Web or sub-Web application may be set to restrict browsing to only registered users. The FrontPage extensions remove read access for the anonymous user from all the content files of the Web application. An anonymous end-user's request to read a page of that Web application is then rejected by the Internet Information Server. End-users must authenticate their identity in the Windows NT domain, and the authenticated user account must have browse access to the Web application before the request will be satisfied. When a user is given browse access to a Web application, the FrontPage extensions grant the user account read access to all the content files of that Web application. (See Run-Time Security Considerations, below.)
For complete control over who can browse a Web application, restrict the Web application so that only registered users can browse it, and then give specific users and/or groups browse access to the Web application.
Run-Time Security Implementation Details
The FrontPage extensions manage run-time Web permissions using the underlying security model of the WWW server software. Here we consider only the case where this is Internet Information Server 3.0 running on Windows NT with the NTFS file system. Security on non-Internet Information Server servers is beyond the scope of this topic. Security features on non-NTFS file systems are severely limited.
FrontPage Run-Time Security
FrontPage manages run-time security differently than design-time security. This is because run-time HTTP requests to read pages are not directed to ISAPI DLLs, as are design-time requests. Internet Information Server goes directly to the file being requested and attempts to read it, as described below. For this reason FrontPage directly alters the ACLs on content files in a Web application in order to control run-time security.
Run-Time Security Considerations
At run time, you might want to allow everyone to read the Web applications pages or restrict access to certain authorized users.
Allowing Access to Any Web Visitor
You can set up your system to allow access to any Web visitor. The following table shows some typical settings you can use to control security for your Web application. Other settings and combinations may produce run-time errors for certain Web visitors.
| Location for setting | Intranet setting | Internet setting |
| Operating system (Windows NT) / Web server | Allow anonymous | Allow anonymous |
| Folder | Permissions are handled through the Web server | Add Anonymous ID to appropriate User Groups, also permissions are handled through the Web server |
| Database | SQL Server - Standard | SQL Server - Standard |
| Web application | Nothing special | Nothing special |
| Page | Nothing special | Nothing special |
Unrestricted Browsing
When a Web application is set to allow unrestricted browsing, FrontPage grants the anonymous user account standard read access to all the content files in that Web application.
Restricting Web Visitor Access
You can restrict access to your Web application by setting security options in several areas. Some developers set up a site that has one Web application with unlimited access for introductory and general content that links to another Web application that is available only to authorized visitors. Typically this second Web application requires the visitor to login so that an ID and password can be compared against a database of registered users.
You can use the following table to help you choose what security options are appropriate for your Web application.
| Location for setting | Intranet setting | Internet setting |
| Operating system (Windows NT)/ Web server (IIS) | Windows NT Challenge/Response (NTLM) Add permissions for User Groups and/or individuals; user groups and password settings must match the operating system |
Basic clear text Add anonymous user ID to appropriate user groups |
| Windows Explorer folder (OS) | Add user group or individuals to permissions list | Add user group or individuals to permissions list |
| Database | Standard | Standard |
| Web application | Global.asa file | Global.asa file – identify authorized users and store session state for a user |
| Page | Use .asp files and server script | Use .asp files and server script |
Registered Users
When a Web application is set to allow only registered users to browse it, FrontPage removes all anonymous user account permissions from the Web application's content files. Since Internet Information Server impersonates the anonymous user during all requests that do not contain user credentials (when Allow Anonymous is checked), this causes such requests to fail initially and begin the authentication process described above.
Securing HTTP Transmissions (SSL)
SSL (Secure Sockets Layer) is a protocol that is used to protect HTTP transmissions from unwanted eavesdropping. Visual InterDev supports the optional use of SSL over the client/server link at design time and when performing a Web Copy operation. You can also use SSL during run time. You choose to use an SSL connection when you create a new Web project or initiate a Web Copy operation.
When an SSL connection is in use, all HTTP requests and replies are encrypted before transmission and decrypted after receipt. This process does require additional time and slows performance.
Except for this encryption/decryption step, all Visual InterDev operations take place exactly as they would over a non-SSL connection. You must obtain and install an SSL certificate on your Web server before you can initiate an SSL connection. For more information on obtaining and installing an SSL certificate on an Internet Information Server, see Securing Your Site Against Intruders in the Internet Information Server documentation.
Administration and Maintenance Considerations
In choosing which settings are appropriate for your Web application and system, you might also consider the administration requirements to maintain your security plan.
For example, if you choose to use Windows NT Challenge Response, the Web permissions are based on the individuals and user groups defined for that server. This setting works well for intranets because user profiles are likely to be setup and maintained on a regular basis and the quantity of user is known. Web permissions can be provided at the same time as network permissions.
If, however, your Web application is running on the Internet and you use the Windows NT Challenge Response, the number of potential requests for profiles could make user administration a full-time job for the system administrator. Also, operating systems typically have a limit on the number of user profiles you can specify.
Simplifying Run-Time Security
As was the case with design-time security, you can simplify the task of managing run-time security by creating a local group, say Web_Readers, on the Web server, and giving the group browse access to the root Web application. Be sure to restrict the root Web application so that only registered users can browse it. When new sub-Web applications are created, keep their default setting of inheriting permissions from the root Web application.
Now the task of permitting a new user to browse the Web applications on this server is reduced to simply adding the new user's name to the Web_Readers group using the Windows NT User Manager. For more information about adding groups, see Setting Web Application Permissions.
Managing Security for Multiple Web Applications
Permission settings are stored and applied on a Web-by-Web basis. You can save time by creating sub-Web applications that inherit the permissions from the root Web above it.
Any changes in root Web permissions apply to all sub-Web applications that inherit from the root Web. An administrator may not change permissions directly on a sub-Web application until it is set to have its own, unique permissions.
Managing Permissions Efficiently
For convenience, Windows NT permits the definition of named collections of users, called "groups". Once a group has been defined and users have been added to it, each user in the group can be granted or denied access to a resource by changing the group's permissions on that resource.