ASP.NET security

Summary
ArcGIS Server Manager (Manager) contains tools that restrict access to Web applications and to geographic information system (GIS) services. This topic discusses ASP.NET security as it relates to the security options in Manager. The purpose of this topic is for developers to understand the security settings and options, and to modify them when appropriate.

In this topic

About ASP.NET security

This topic covers authentication, authorization, and confidentiality. Security for an ASP.NET application includes the following features:
  • Authentication—Determines who is requesting to use the application.
  • Authorization—Restricts access to designated users and roles.
  • Confidentiality and secure communication—Ensures sensitive data is stored properly and cannot be intercepted during transmission.
  • Intrusion prevention and detection—Prevents viruses, Trojan code, worms, and so on, from interfering with proper operation.
  • Code security—Prevents code vulnerabilities, such as cross-site scripting, Structured Query Language (SQL) injection, and buffer overflows.
  • Physical security—Protects hardware from unauthorized access, tampering, and theft.
For more information about security, consult your local computer security expert or books and Web sites on ASP.NET and security. One resource is the Microsoft Security Developer Center, which has many how-to topics and checklists, including Cheat Sheet: Web Application Security Frame that summarizes vulnerabilities. Watch for code vulnerabilities in particular. Validate any data that is entered by end users before using it in an application.

ArcGIS Server Manager security tools

Manager has tools that perform the following operations:
  • Create, edit, and delete users and roles.
  • Specify the location where users and roles are stored. Options include Windows users and groups, Microsoft SQL Server, and custom provider locations.
  • Enable security and manage permissions for GIS Web services.
  • Enable security and manage permissions for Web applications.
For more information regarding these tools, see the ArcGIS for Server Help. Access the Server Help, which is installed locally, by clicking Start, All Programs, ArcGIS, ArcGIS Server for the Microsoft .NET Framework, ArcGIS Server Help. The same Server Help is also available on the ArcGIS Resource Center. Once in the Server Help, see the topics under Administering ArcGIS for Server, Securing your system, Securing Internet connections and Web applications.

Users and roles

Users and roles are not stored in ArcGIS for Server. Their location depends on the user and role location specified in Manager and stored in the security web.config file. Whether Manager can be used to manage users and roles depends on whether the membership and role provider support the membership and role application programming interface (API) methods for managing users and roles as follows:
  • Windows—Users and roles are stored as standard operating system (OS) users and groups, either on the local server or on the domain. Users and groups must be managed with standard Windows OS tools.
  • Microsoft SQL Server—Users and roles are stored in the database specified in Manager. The <connectionStrings> element specifies how the security application connects to the database. The database is typically stored in the SQL Server default data folder, not in the individual Web application. This is because the database can be used to authenticate users in multiple Web applications. Manager can be used to manage users and roles in the database.
  • Custom provider—Users and roles are stored in a location determined by the provider. For example, Active Directory can be configured as a custom provider, in which case users are stored in the Active Directory server. Another option is a file-based provider, where users are stored in a file on disk. To use a custom provider, configure the provider manually in the security web.config file. See the ArcGIS for Server Help for details on this procedure. If the custom provider supports .NET API methods, Manager can enable users and roles.
  • Anonymous, Everyone, and Authenticated—Roles (also called generic roles) are supported by ArcGIS for Server to enable access to authenticated or non-authenticated users. These generic roles are used only with GIS Web services. Generic roles are not used when managing security for Web applications. Generic roles must be added to the role provider before use. If roles are stored in SQL Server, you can add them when configuring the role store. For more information, see the ArcGIS for Server Help. To use these roles with a custom provider, you must add the roles to the custom provider store. These roles are not used when the roles are Windows groups. Generic roles must be added to the role provider with special characters. Do not add them with the actual name; use the special single-character format as follows:
    • Anonymous—Add a role named ?
    • Everyone—Add a role named *
    • Authenticated users—Add a role named @
    • Do not add users to generic roles.
  • Web Site Administration Tool—If the membership and role providers support editing users and roles in Manager, you can use the Web Site Administration Tool (WSAT) to manage users and roles. WSAT is included with Visual Studio (and Visual Web Developer Express) as a Web site management tool. To access WSAT, open the Web site in Visual Studio and select ASP.NET Administration from the Web site menu. WSAT opens in a separate Web browser window. To manage users and roles for ArcGIS for Server, open either the ArcGIS security Web application or the Web site where you have applied security with Manager. All applications secured with Manager share the same database for users and roles, so you can use any of them to access WSAT.

User and role store location

When you save Manager security settings, the settings are written to the web.config file of the security application in the ArcGIS instance. For a typical installation of ArcGIS for Server, this location is C:\Inetpub\wwwroot\ArcGIS\Security\web.config. The security application is mainly a holding place for the security settings. Since the store location can be specified before applying security to services or applications, the security application enables Manager to save settings until they are used. The settings are copied to other applications as described in the Security for GIS Web services and Security for Web applications sections.
The settings saved in the security web.config file are standard ASP.NET configuration settings and can include the following elements:
  • membership—Location of the user store. Always created.
  • roleManager—Location of the role store. Always created.
  • authentication—Determines whether to get user credentials via a form or via a Windows login. Created if the user store is not a Windows user.
  • connectionStrings—Connection strings for a database used for the user and role store. Created if using Microsoft SQL Server for users or roles.
  • mailSettings—Mail server and user information used to send e-mail to users when recovering a password. Created if mail settings are specified in the security settings wizard in Manager. Not available when the user store is a Windows user.
For more information on these configuration elements, see references on ASP.NET. A reference guide for elements in the configuration file is available at ASP.NET Configuration File Syntax on the Microsoft Developer Network (MSDN) Web site.
The PasswordManager.aspx security application Web page is accessible to users. When the security membership provider allows it, this page enables users to change their password and to recover a lost password. You can add a link to this page outside a Web application so that users can manage passwords separately from an individual application.

Security for GIS Web services

Security for GIS Web services involves the following steps:
  1. Use Manager to set permissions for services.
  2. Use Manager to enable security for services.
Set initial permissions for services before enabling security, because if security is enabled before any permissions are assigned, no one will be able to access GIS services. Permissions can be edited at any subsequent time.
Security for GIS Web services is applied internally by the ArcGIS for Server Object Manager (SOM). No permission information is stored in the ArcGIS instance's services Web application. Instead, permissions are stored in the SOM configuration files. For more information on configuration files, see the ArcGIS Server Help.
When you use Manager to enable security for GIS Web services, Manager copies the security settings from the ArcGIS security application to the following applications (all in the same ArcGIS instance):
  • Rest
  • Services
  • Tokens
These applications contain elements for the following:
  • <membership>
  • <roleManager>
  • <authentication>
  • <connectionStrings> if available
  • <mailSettings> if available
This enables security to be applied to the Web service APIs for working with GIS services, Representational State Transfer (REST) and Simple Object Access Protocol (SOAP). It also allows the Tokens application to access the membership provider to authenticate the user when tokens are used. For more information, see Working with the REST API and Working with the SOAP API.
In ArcGIS, tokens are automatically enabled for service access when appropriate. When SQL Server or a custom provider is the user store, tokens are enabled. When Windows users are chosen, tokens are disabled by default. For more information on tokens, see the ArcGIS for Server Help topics on security.
Web Application Developer Framework (ADF) controls automatically acquire and use tokens when an identity is supplied. When using the SOAP or REST API, you must acquire and use tokens explicitly. For more information, see the respective API overviews.
The security restrictions discussed in this topic do not apply to local connections to GIS services. Local connections are secured through the Distributed Component Object Model (DCOM) security methods described in the ArcGIS Server Help.

Security for Web applications

To secure a Web application, select the option in Manager to enable security for the application, then add permitted roles to the application. When permissions are saved, Manager writes the permission rules and other security settings into the configuration for the Web application.
The changes that are made to the Web application web.config file when security is applied are as follows:
  • The settings for security in the ArcGIS security application are copied to the Web application. These settings have been previously described and can include elements for the following:
    • <membership>
    • <roleManager>
    • <authentication>
    • <connectionStrings> if available
    • <mailSettings> if available
  • The <authorization> element is added (or modified) to deny all users (that is, a tag for <deny users="*" /> is added)
  • The <authorization> element is modified to add <allow> rules for roles in the permitted-roles list in the Manager dialog box. The allow rules are added before the deny-all-users rule.
If you change the Manager security settings using the wizard in Security-Settings, the settings are updated in each Web application that Manager lists on the Applications tab if the application has been secured.
If the Web application uses ArcGIS for Server Web services that are secured, the resource manager control stores an encrypted version of the username and password on the application page. This information is used to authenticate with the GIS server and to obtain a token automatically if required. The Web ADF controls automatically renew the token if it expires.
For more information on editing and deploying Web applications secured with Manager, see the Deployment section.

ASP.NET security considerations

This section briefly discusses some security aspects of ASP.NET applications.

Authentication

Authentication is the process of determining and validating the identity of the user of the application. ASP.NET applications typically authenticate users by the following methods (a third method, Passport, is rarely used):
  • Windows—The application relies on the underlying Web server (the Internet Information Server [IIS]) to authenticate the user. This in turn means that the user has an account on the OS of the local Web server or on the domain where the server is a member.

    How IIS authenticates the user depends on the Authentication Methods setting in IIS for the application. If IIS is set to use Integrated Windows authentication, and the user is on the local network using Internet Explorer, the user's Windows identity is automatically detected and no login screen is displayed.

    If IIS is set to Basic or Digest authentication (or Integrated Windows, and the user is on a non-Internet Explorer Web browser), the user is authenticated by a pop-up login dialog box that cannot be customized. However, if IIS is configured to allow anonymous access, no authentication occurs and the account configured in IIS for anonymous access is used (unless the <authorization> element in the application denies access to anonymous users).
  • Forms—The application uses a Hypertext Markup Language (HTML) form to authenticate the user. This is the most common method used for Internet applications. A login form must be added to a page in the application, and the page must be identified with a loginUrl attribute in a <forms> tag within the authentication element. The default for the login is a page called login.aspx. When a user attempts to access the application, and the <authorization> tag prohibits anonymous access, the user is redirected to the login page. This page must contain logic to authenticate the user.
The authentication choice is recorded in the web.config file of the application in the <authentication> element, as shown in the following code example:
[HTML] 
<authentication mode="Forms"/>
Manager sets the authentication mode to Forms unless Windows is selected as the user store (and the token service is not enabled).

Authorization

Authorization is the process of determining whether a user is permitted to access an application or resource. Typically, the Web application authenticates the user to obtain an identity, then uses the identity to test whether the user has access. In ASP.NET applications, authorization is usually configured using the <authorization> element in the web.config file.
The authorization element can contain one or more rules to allow or deny access to users or roles. For example, the following rule allows users in the Editors role to access the application, and denies access to all other users ("*" means all users):
[HTML] 
<authorization>
  <deny roles="FieldCrew"/>
  <allow roles="Editors"/>
  <deny users="*"/>
</authorization>
To determine whether a user has access, the rules are checked, starting with the first rule and proceeding to the end of the list. The first matching rule found is applied. If rules conflict, the first rule encountered that applies to the user is enforced. In the previous rules example, if a user is in both the FieldCrew and Editors roles, the user is denied access, since the deny rule is encountered first.
Roles are more often used for authorization rules because they are easier to maintain—when a user is added or removed from the system, the authorization rules do not need to be changed when using roles. Role membership is determined using the Role Manager.
Manager adds authorization rules when you set permissions for a Web application. Manager does not use deny rules, it only uses allow rules. The sole exception is that the deny-users-all rule is added to the bottom of the list, to exclude users not specifically permitted. Hence, the previous rule example would not occur when using Manager to set permissions, because the first deny rule would not occur.
If you need to customize the authorization rules, for example, to add deny rules, do not use Manager to edit permissions for the application. If you do, your custom rules will be overwritten.
Some applications can require that users be allowed to access one or more pages without logging in. For example, a page might have a basic map and information for public users, with a link to the full mapping page that requires a login. You can enable these open pages by including <location> elements in the web.config file.
Each <location> element points to a folder or resource to which special authorization rules apply. For example, a Web site might store open-access pages in a folder in the Web site called "public." To allow users to access pages in this folder without a login, add the following rule to the web.config file, within the <configuration> section (but outside the <system.web> section):
[HTML] 
<location path="public">
  <system.web>
    <authorization>
      <allow users="*"/>
    </authorization>
  </system.web>
</location>
Always place open-access pages that use Web ADF controls (such as Map) in a folder, rather than at the Web site root. Add the <location> element for the folder to allow all users. This is necessary because the ADF controls use script and image resources that are referenced at the relative path of the page. If you placed the page at the Web site root, the authorization rules would not allow open access to the required resources for the ADF controls on the public page.

Membership and role manager

ASP.NET has a framework for storing and validating users and roles. The Membership and Role Management APIs are standardized methods for accessing collections of users and roles. This allows an application to check for users and roles in a standard way, without concern for how the data is stored. The same methods can be used to access users and roles stored in a variety of locations, such as a database, a file, or a Lightweight Directory Access Protocol (LDAP) server. An implementation of the API for a type of data source is called a provider. The provider is often compiled into a .NET assembly (a dynamic-link library [DLL]). It must then be added to the application's configuration, usually by adding it to the web.config file.
The membership and role manager elements in the web.config file configure the way the application validates users and roles. The <membership> element specifies the membership provider, while the <roleManager> element configures the role management provider.
Manager adds these elements to a Web application when the application is secured in Manager. Manager copies the settings from the ArcGIS security application. If you change the user or role store with the Manager Security-Settings wizard, Manager updates the ArcGIS security application and all Web applications in its application list that have been secured and that have permissions applied.

Secure communications and SSL

When users are required to log in to an application, ensure that passwords and any other sensitive information cannot be intercepted during transmission. The typical way of protecting transmission of data on the Internet is to require the use of Hypertext Transfer Protocol Secure (HTTPS), which uses Secure Sockets Layer (SSL) for encrypting data. All modern Web browsers support SSL, but you need a certificate on your server to use SSL. For information on obtaining an SSL certificate, see the ArcGIS for Server Help, under the topic Setting up SSL (at Administering the server, Securing your system, Securing Internet connections and Web applications).

Deployment

When you deploy an application from a development server to a production server, and the application has security applied, ensure that the membership and role provider data source is available at the production server.
For example, if the users and roles are stored in a database, the database must be available from the production server. You might need to move or copy the user and role data to a location that is available to the production server. If the location or connection process changes, you might also need to update the connection strings, membership, or roleManager elements in the web.config file of the application.
For more information on deployment, see Licensing and deployment.