Multiple ArcGIS Server Web instances for security

An ArcGIS Server instance supports only one combination of user location, role location, and authentication method (for more information on users and roles, see the Overview of setting up users and roles). If you need to support more than one type of authentication or user/role store, then you can set up multiple ArcGIS Server instances.

Normally, each ArcGIS Server system has one instance, which is tied to a single Server Object Manager (SOM). This section describes the configuration where multiple ArcGIS Server instances are tied to a single SOM.

For example, you may have users on your internal network and want to allow them to log in with their Windows accounts. But for external users on the Internet, you want to set up accounts in a SQL Server database. Since an ArcGIS Server instance only supports a single user location, you would set up separate instances for each user type.

You need to think about two issues when managing multiple instances:

• Permissions for Internet connections to services are stored in the SOM. If multiple instances work with the SOM, the instances will share the same set of permissions. Since permissions are based on roles, you need to manage permissions carefully so that roles, and hence users, in each instance work correctly. See the section below, Managing permissions with multiple instances, for more information.
• If you enable the Web Mapping Service (WMS) capability for a service, the capabilities information for the service is shared by all instances. The OnlineResource URL for the service will be set to one of the instances. For further information, see Knowledge Base article 35672, Why does the OnlineResource URL in the WMS capabilities use a different ArcGIS Web instance?.

Adding an ArcGIS Server instance

A utility for adding and removing instances is included at <ArcGIS Server installation directory>\DotNet\AddInstance.exe. You can double-click this executable from Windows Explorer to open the tool. Follow the instructions in the wizard for adding a new instance.

The name you choose for the instance will be reflected in the URL that others use to access the instance. For example, if you enter ArcGIS2, then the services URL might be http://myserver/ArcGIS2/services.

Once you finish the wizard, it can take several minutes to create the instance. If you decide later to remove an instance, you can use the same utility.

Using the new instance

The new instance has its own Manager. To access it, go to Start > (All) Programs > ArcGIS > ArcGIS Server for the Microsoft .NET Framework > ArcGIS Server Manager <instance name>. Use the new Manager to configure the user and role store for the new instance. You will notice that the Services panel lists the same services as the original Manager and that the permissions for services are also the same. See the next section for important information on managing permissions across multiple instances.

The new instance will not list the Web applications created with a different instance. Each instance maintains its own list of applications created with that instance.

Each instance is located in the IIS Web server directory where you created the instance. For example, if you created a new instance named ArcGIS2 in the Default Web Site on port 80, and the IIS server uses the default location, the location for the instance will be at C:\Inetpub\wwwroot\ArcGIS2. The new instance will contain the same set of folders as the original instance, including Rest, Services, and Security.

Managing permissions with multiple ArcGIS Server instances

Since permissions are stored in the SOM, multiple ArcGIS Server instances sharing the SOM will also share the same set of permissions for services. When you click the Permissions button for a service or folder, you will see the permissions for roles that have been added with either instance's Manager.

You must manage the permissions for folders and services so that users in both instances can access services appropriately. Since permissions are based on roles, rather than users, you must ensure that the roles for each instance are allowed for services as needed. Since administrators using either Manager see the same list of permitted roles, it would be possible to mistakenly remove a role that had been allowed in the other Manager.

One of the following two strategies is recommended for managing roles and permissions:

• Use the same names for roles in both instances, and add users in each instance to these shared roles. This is appropriate if you want to allow users in both instances to access services with the same permissions rules. For example, you might add a group named Planners to the Windows groups on your server and add Windows users to the group. Then, in the Manager that uses SQL Server for roles, you also add a Planners role and add SQL Server users to the role. Then, when you permit the Planners role to access a service, users from both instances can use the service through the one permission rule for Planners.
• Use recognizably different names for the roles in the two instances. This is appropriate if you want different rules for users in each instance. For example, you might create a Windows group named InternalEditors for internal users, and in the Manager set to use SQL Server for roles, add a role named ExternalViewers. The Internal and External prefixes indicate the different location of each role, so that someone using Manager in one instance would not mistakenly remove a role added for the benefit of users in the other instance.

Note:

If one of your instances uses ASP.NET membership, be aware that the three built-in roles (Everyone, Authenticated User, and Anonymous) will span all instances. For example, suppose you are using the Microsoft SQL Server membership provider for one instance and the Windows operating system users and groups for the second. If you grant access to the root Web service folder in the SQL Server instance, all Windows users will be able to see all Web services when they connect.