Developing Web Applications with the Web ADF - ASP.NET Integration  

ASP.NET Security



ArcGIS Server Manager contains tools to restrict access to Web applications and to GIS services. This page discusses aspects of security in ASP.NET relating to the options that Manager applies. The purpose is to enable developers to understand these settings, and to modify them where appropriate.

Security for an ASP.NET application has many aspects, including

This page discusses only authentication, authorization and confidentiality. For more information on security, consult your local computer security expert, or books and websites on ASP.NET and security. One resource is Microsoft's Security Developer Center, which has many how-to's and checklists, including a useful Cheat Sheet: Web Application Security Frame that summarizes vulnerabilities. Developers should in particular watch for code vulnerabilities. Any data that is entered by end users should be validated before being used in the application.


ArcGIS Server Manager Security Tools

ArcGIS Server Manager has tools to:

See the ArcGIS Server Help for details on using these tools. The Server Help is installed locally at Start-(All) Programs-ArcGIS-ArcGIS Server for Microsoft .NET Framework-ArcGIS Server Help. The same Server Help is also available online at ESRI. Once in the Server Help, see the pages under Administering the server - Securing your system - Securing Internet connections and Web applications.

The remainder of this page explains details on how these options are applied, and how as a developer you can work with these settings.

User and role store location

When the Manager user saves security settings, these settings are written to the web.config file of the Security application inside the ArcGIS instance. For a typical installation of ArcGIS Server, this location would be C:\Inetpub\wwwroot\ArcGIS\Security\web.config. The Security application is mainly a holding place for these security settings. Since the store location can be specified before actually applying security to services or applications, the Security application enables Manager to save settings until they are used. These settings are copied to other applications as described below under Security for GIS Web services, and under Security for Web applications.

The settings saved in the Security web.config are standard ASP.NET configuration settings. The settings may include the following elements:

For more information on these configuration elements, see references on ASP.NET. A reference guide for elements in the configuration file is available at this page at Microsoft MSDN: ASP.NET Configuration File Syntax.

The Security application does have one web page accessible to users: PasswordManager.aspx. When the security membership provider allows it, this page enables users to change their password and to recover a lost password. If desired, you may add a link to this page outside any Web application so that users may manage passwords separately from any individual application.

Users and roles

Users and roles are not stored within the ArcGIS Server. The actual location depends on the user and role location specified in Manager and stored in the Security web.config.

Whether Manager may be used to manage users and roles depends on whether the membership and role provider support the membership and role API methods for managing users and roles.

Anonymous, Everyone and Authenticated roles: ArcGIS Server supports these special roles to enable access to authenticated or non-authenticated users. These roles are used only with GIS Web services. These roles are not used when managing security for Web applications. In order to use these generic roles, they must be added to the role provider. If roles are stored in SQL Server, you may add these roles when configuring the role store; see Server Help for details. If you wish to use these roles when using a custom provider, you must add them to your custom provider's store yourself. These roles are not used when the roles are Windows groups.

These roles must be added to the role provider with the following special characters. Do not add them with the actual name; instead, use the single-character format show here:

Do not add any users to these generic roles.

Web Site Administration Tool (WSAT): if the membership and role providers support editing users and roles in Manager, then you may also use the Web Site Administration Tool to manage users and roles. WSAT is included with Visual Studio (and Visual Web Developer Express) as a tool to manage websites. To access WSAT, open the website in Visual Studio, then choose in the menu Website-->ASP.NET Administration. WSAT opens in a separate browser window. To manage the users and roles for ArcGIS Server, open either the ArcGIS/Security web application or any website where you have applied security with Manager. All applications secured with Manager share the same database for users and roles, so any of them may be used to access WSAT.

Security for GIS Web services

Security for GIS Web services involves two steps: first, the Manager user sets permissions for services, and second, the Manager user enables security for services. At least some initial permissions should be set for services before enabling security. The reason is that if security is enabled before any permissions are assigned, then no one will be able to access any GIS services. Permissions may be edited at any subsequent time as well.

Security for GIS Web services is applied internally by the ArcGIS Server Object Manager (SOM). No permissions information is stored in the ArcGIS instance's Services web application. Instead, permissions are stored in the SOM's configuration files. See the Server Help for more information on these configuration files.

When the Manager user enables security for GIS Web services, Manager copies the security settings from the ArcGIS/Security application to three other applications, all in the same ArcGIS instance: Rest, Services, and Tokens. These include the elements for <membership>, <roleManager>, <authentication> and, if available, <connectionStrings> and <mailSettings>. This enables security to be applied to the two Web service APIs for working with GIS services, REST and SOAP. It also allows the Tokens application to access the membership provider to authenticate the user, when tokens are used.

At 9.3, tokens are automatically enabled for service access when appropriate. When SQL Server or a custom provider is chosen for the user store, tokens are enabled. When Windows users are chosen, tokens are not enabled by default. For general information on tokens, see the ArcGIS Server Help topics on security. Web ADF controls automatically acquire and use tokens when an identity is supplied. When using the SOAP or REST APIs, you must acquire and use tokens explicitly; see the respective API overviews for information.

Note that security restrictions discussed here do not apply to Local connections to GIS services. These connections are secured through the DCOM security methods described in the Server Help.

Security for Web applications

To secure a Web application, the Manager user checks the option to enable security for the application, and then adds permitted roles to the application. When the permissions are saved, Manager writes the permission rules and other security settings into the configuration for the Web application.

The changes made to the Web application's web.config when security is applied are:

If the user in Manager changes the settings for security by using the wizard in Security-Settings, the settings are also updated in each Web application that Manager lists in its Applications tab, if the application has been secured.

If the Web application uses ArcGIS Server Web services that are secured, the resource manager control will store an encrypted version of the username and password in the application page. This information will be used to authenticate with the GIS server, and to obtain a token automatically if required. The Web ADF controls will also automatically renew the token if it expires.

For more information on editing and deploying Web applications secured with Manager, see the section below on Deployment Issues.


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 authenticate users in one of two common ways (a third option, Passport, is rarely used):

The authentication choice is recorded in the web.config file of the application in the <authentication> element, for example: 

<authentication mode="Forms" />
Manager sets the authentication mode to Forms unless Windows is chosen 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 first authenticates the user to obtain an identity, and then this identity is used 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 rule below allows users in the Editors role to access the application, and denies access to all other users ("*" means all users):

<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 example of rules above, if a user is in both the FieldCrew and Editors roles, then the user will not be permitted 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 (see below).

Manager adds authorization rules when the Manager user sets permissions for a Web application. Manager never uses deny rules, only allow rules. The only exception is that the deny-users-all rule is added to the bottom of the list, to exclude users not specifically permitted. Hence the example above would not occur when using Manager to set permissions: the first deny rule would not occur.

If you need to customize the authorization rules, such as to add deny rules, you should not use Manager subsequently to edit permissions for the application. If you do, your custom rules will be overwritten.

Some applications may require allowing users to access one or more pages without logging in. For example, a page might have a very 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. Each <location> element points to a folder or resource to which special authorization rules apply. For example, a website might store open-access pages in a folder in the website called "public". To allow browsers to access pages in this folder without a login, add this rule to the web.config file, within the <configuration> section (but outside the <system.web> section):

<location path="public">
    <system.web>
      <authorization>
        <allow users="*"/>
      </authorization>
    </system.web>
  </location>

Open-access pages that use Web ADF controls (Map, etc.) should always be placed in a folder, rather than being placed at the website root. Then add the <location> element for the folder to allow all users. This is because the ADF controls use script and image resources that will be referenced at the relative path of the page. If the page were placed at the website 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 API and Role Management API 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 are actually stored. The same methods may be used to access users and roles stored in a variety of locations, such as a database, a file, or an 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 (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 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 Manager's Security-Settings wizard, Manager will update both the ArcGIS/Security application, as well as all Web applications in its application list that have been secured and permissions applied.

Secure communications and SSL

When users are required to login to an application, you should 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 HTTPS, which uses Secure Sockets Layer (SSL) for encrypting data. All modern browser support SSL, but you will need a certificate on your server to use SSL. For information on obtaining an SSL certificate, see the ArcGIS Server Help, under the topic Setting up SSL (at Administering the server - Securing your system - Securing Internet connections and Web applications).

Deployment issues

When you deploy an application from a development server to a production server, and the application has security applied, you must 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, then the database must be available from the production server. You may need to move or copy the user and role data to a location available from the production server. If the location or connection process changes, you may 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.