jscript editor
Web designer
Role management enables you to manage authorization for your application with categories you create, referred to as "roles." By assigning users to roles, you can control access to different parts or features of your Web application based on a role instead of, or in addition to, a user name. For example, an employee application might have roles such as Managers, Employees, Directors, and so on, where different privileges are specified for each role.
Users can belong to more than one role. For example, if your site is a discussion forum, some users might be in the roles of both Members and Moderators. You might define each role to have different privileges on the site, and a user who is in both roles would then have both sets of privileges.
While following coding and configuration best practices can improve the security of your application, it is also important that you continually keep your application server up to date with the latest security patches for Microsoft Windows and Internet Information Services (IIS), as well as any patches for Microsoft SQL Server, Active Directory, or other role data sources.
For more detailed information about best practices for writing secure code and securing applications, see the book "Writing Secure Code" by Michael Howard and David LeBlanc and the guidance provided by Microsoft Patterns and Practices (
Secure Role Manager Configuration
The role-manager feature is disabled by default for ASP.NET applications to improve the security of applications that do not use the role manager. When the role-manager feature is enabled, the default configuration settings are set to the most secure values. For information about role-manager configuration settings and their default values, see
Securing Configuration Values
When storing sensitive information in a configuration file for an application, you should encrypt the sensitive values using Protected Configuration. Information that is especially sensitive includes the encryption keys stored in the
Secure Encryption Keys and Hashing
It is highly recommended that you protect role names cached in a cookie by setting the cookieProtection attribute of the
On a server that hosts multiple applications, you should define unique encryption keys for each application. A less secure alternative is to define a single encryption key and specify the IsolateApps option with the key.
Host servers can also restrict the ability to override configuration settings from the machine configuration by denying override rights. This includes denying the ability for encryption keys to be redefined in the Web.config file for an application.
Securing Connections to a Role Data Source
Connection Strings
As mentioned earlier, it is important to protect the connection string that is used to access SQL Server, Active Directory, or another data-source application. To keep the connection to your database server secure, you should encrypt connection-string information in the configuration by using Protected Configuration. For more information, see Encrypting Configuration Information Using Protected Configuration.
Connecting to SQL Server Using Integrated Security
To connect to computers running SQL Server, you should use Integrated Security to avoid the possibility of your connection string being compromised and your user ID and password being exposed. When you specify a connection that uses Integrated Security to connect to a computer running SQL Server, the role-manager feature reverts to the identity of the process. You should ensure that the identity of the process (for example, the application pool) that is running ASP.NET be the default process account or a restricted user account. For more information, see ASP.NET Impersonation.
SQL Server Database Permissions
The SQL Server database that is used to store the user information for roles includes database roles and views that enable you to restrict user access to only the required capabilities and visibility. You should assign minimum privileges to the user ID that is used to connect to the SQL Server role database. For more information, see
SQL Server Express Worker Process Identity
SQL Server Express 2005 includes a new mode of operation that allows SQL Server to start a worker process running as the identity of the connecting user. This capability is referred to as "run as user" mode. Although this mode of operation is suitable for desktop development when using IIS, starting worker processes is not appropriate on Web servers hosting multiple, untrusted customer codebases. Shared hosting servers that contain applications that do not trust each other should explicitly disable the "run as user" functionality. This functionality can be turned off by connecting to the SQL Express instance (for example, osql –E –S .\sqlexpress) and issuing the following Transact-SQL command.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Securing the Authorization Store
To improve the security of your data source when using the
The role-manager feature reverts to the identity of the process when connecting to an Active Directory server. You should ensure that the identity of the process (for example, the application pool) that is running ASP.NET is the default process account or a restricted user account. For more information, see ASP.NET Impersonation. Additionally, you should assign permissions to the account in the Active Directory authorization store that allow access to only the specific Authorization Manager application or scope required by your ASP.NET application.
You should use a network encryption tool such as Internet Protocol Security (IPSec) to protect the connection to the Active Directory server.
Securing the Role Cookie
You can specify that role names for a user be cached in a session cookie to improve performance by setting the cacheRolesInCookie attribute of the
Preventing Cookies Being Shared Across Applications
If the cacheRolesInCookie attribute of the
To avoid sharing the role names cookie across multiple applications, specify separate encryption keys in the
Secure Web Pages that Use Roles
Application pages that work with sensitive data, such as logon pages, should be secured using standard Web security mechanisms. These include using Secure Sockets Layer (SSL) and requiring that users be logged on to carry out sensitive operations like updating user information or deleting users.
Additionally, pages should not expose sensitive feature data such as passwords, and in some cases user names, in clear text. Ensure that pages that display such information make use of SSL and are available only to authenticated users. Also, avoid storing sensitive feature data in cookies or sending it across insecure connections.
Securing Against Denial of Service Attacks
Methods that perform updates or large search operations can reduce the responsiveness of your role data source if called concurrently by a number of clients. To reduce your exposure to a denial of service attack, restrict access to ASP.NET pages that make use of methods that perform database updates or searches to administrative users, and expose only ASP.NET pages that provide validation of role membership for general use.
Error Messages and Events
Exceptions
To prevent sensitive information from being exposed to unwanted sources, configure your application either to not display detailed error messages or to display detailed error messages only when the client is the Web server itself. For more information, see
Event Log
If your server is running Windows ServerВ 2003, you can improve the security of you application by securing the event log, and by setting parameters regarding the size, retention, and so on of the event log to prevent an indirect denial of service attack against it.
Trace Information
Your Web server can be configured to trace when certain actions occur regarding the role-manager feature and store the trace information in a log file. Because sensitive information such as user names and role names can be stored in the trace log file, you should restrict access to the ability to enable tracing to administrators only as well as the ability to configure the location of the trace log file and access to the trace log file.
Custom Role Providers
When creating a custom role provider, ensure that you follow security best practices to avoid attacks such as SQL injection attacks when working with a database. When making use of a custom role provider, ensure that the provider has been reviewed for security best practices.
See Also
