|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Web Site Administration Tool Security Tab
Use the Security tab of the Web Site Administration Tool to manage rules for securing specific resources in the Web application. ASP.NET uses a security system that lets you restrict access to specific user accounts or the roles to which the user accounts belong. With the Security tab, you manage user accounts, roles, and access rules for the Web site. Before using the Security tab for the first time, use the Security Setup Wizard to configure basic security settings for the Web site.
ASP.NET security is based on the concepts of user accounts, roles, and access rules and lets you restrict access to your Web application resources to only the user accounts that you specify. Security settings are established using a combination of configuration settings and data stored in a database (or other data store). User accounts and roles that you create are stored in the database and access rules are stored in the Web.config file.
You can configure your application to use the following types of security, which depend on how the Web site will be used:
Forms-based authentication (From the Internet)
Forms-based authentication is used for Web sites that are made available to the Internet. Forms-based authentication uses the ASP.NET membership system to manage individual user accounts and groups (roles). User account information is stored in a local database or in a Microsoft SQL Server database. You can use the ASP.NET logon controls to create a logon page where users can enter their credentials.
Integrated Microsoft Windows authentication (From a local network)
Windows authentication interacts with Windows security, using the logon credentials that users provide when they log on to Windows. Therefore, Windows authentication is suited for intranet scenarios, where users have logged on to a Windows-based network. You do not have to create a logon page, because users are automatically logged on to your application with their Windows credentials.
Use the Users section of the Security tab to complete the following tasks:
Create, edit, and delete registered user accounts for the Web site.
View a list of all registered user accounts for the Web site.
Change the authentication method that is used by the Web site.
You can create and manage user accounts, if you chose the From the Internet option for your authentication type (if you are using forms-based authentication). If you chose the From a local network option as your authentication type (if you using integrated Windows authentication), you cannot manage individual user accounts. If you change the authentication type, any user information that you have created will be lost. Additionally, access rules might no longer work in the way that you configured them. Generally, you should select an authentication type only when you first configure the Web site.
Use the Roles section of the Security tab to group user accounts, which makes it easier to assign permissions (authorization).
Use the Access Rules section of the Security tab to allow or deny access for specified pages to specific user accounts or to all user accounts that belong in a specified role. Typically, you use an access rule to restrict pages for some user accounts.
You can create and manage user accounts, if you have set the authentication type to From the Internet (forms authentication). To change authentication types, click Select authentication type.
To create user accounts
Click Create user, and then specify the following information.
Enter the name for the user account to create.
Enter the password for User Name. Passwords are case sensitive.
Enter the e-mail address for User Name.
The Web Site Administration Tool does not confirm whether the address that you enter is a valid e-mail address, but it does validate that the e-mail address conforms to the correct format for e-mail addresses.
Enter a question to ask the user when they need to reset or recover their password.
Enter the answer to Security Question.
Select this option to enable this user account as an active (current) user of the site. If you do not select this option, the user information is stored in the database, but the user cannot log on to the Web site.
Select the roles for User Name. You create roles separately. For more information, see the next section.
To create roles
On the Security tab, click Enable roles.
Click Create or Manage roles.
In the New role name box, enter a name for the role to create, such as Administrator, Member, or Guest, and then click Add Role.
To add user accounts to roles
On the Security tab, click Manage Users, and then click Edit User.
Under Roles, select the roles for the user account.
Creating Access Rules
To create access rules
On the Security tab, click Create access rules.
Specify the following options:
Select a directory for this rule
You can choose to create a rule that applies to the whole site or to only a specific subdirectory. In the directory structure display for the Web site, select the directory to which the rule applies.
Under Rule applies to, specify how to apply the rule.
Select Role, and then in the list, select the name of the role to which the access rule applies.
Select User, and then enter the name of the user account to which the access rule applies. If you are using ASP.NET membership (Web site security is set to From the internet), you can also use the Search for users feature.
Select this option to apply the rule to all visitors to the Web site.
Be careful when you create a rule with the All users option. Because rules are applied in order, you can unintentionally create a rule that prevents all users from accessing a folder.
Select this option to apply this rule to anonymous (non-registered) user accounts only.
Typically, you choose the Anonymous users option to restrict (deny) access for users who are not logged on.
Select Allow to give access to the specified directory for the specified user account or role.
Select Deny to not allow access to the specified directory for the specified user account or role.
For example, to prevent users who are not logged on (anonymous) from viewing pages in a folder, click the folder, select Anonymous users, and then select Deny.
Sometimes, you might have to create multiple rules for the same folder in order to establish the correct permissions. For example, you might create a rule that denies access to anonymous user accounts and a second rule that denies access to user accounts in the role of Guest. That way, only users who are logged on and in another group can access the folder.
Behind the Scenes
The Web Site Administration Tool manages security information in the following two places:
The Web.config file at the root of the Web site.
The site provider database that is used to store user and group information.
The Web.config settings that are managed through the Security tab are the <authorization>, <roleManager>, and <authentication> sections.
The following code example is the Web.config file that is created by the Web Site Administration Tool within a restricted subdirectory of the Web site. Access to the restricted subdirectory is allowed for administrators and denied for anonymous users.
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.web> <authorization> <allow roles="administrators" /> <deny users="?" /> </authorization> </system.web> </configuration>
When you use the default data provider, the Web Site Administration Tool creates entries in the default ASP.NET database. By default, the Web Site Administration Tool creates a database in the App_Data folder of the Web site. However, using the Provider tab, you can specify that application information for user accounts and roles be kept in another database (for example, retrieving role information from the Windows user database). For detailed information, see.
For more information about the settings that are managed in the Security tab, in the .NET Framework documentation, see the following topics: