Securing Web services
When Web services are secured, clients requesting access to these Web services must belong to a role that has been granted access to that particular Web service. You can administer permissions on ArcGIS Web services using ArcGIS Server Manager.
Setting permissions on a folder
To efficiently administer permissions on multiple ArcGIS Web services, you can organize Web services into folders and assign permissions to a folder. The roles granted access to a folder automatically acquire access to the subfolders and Web services contained within that folder. Folder-level permissions are a convenient way to manage access to all the resources (folders and services) contained within the folder.
To set permissions on a folder in the ArcGIS Server Manager, navigate to the Manager Services page on the Services panel and click the drop-down list on the top of the page next to the Services In label. Click the adjacent Edit Folder Permissions icon. A dialog box appears listing all the roles that have permission to access the folder along with a list of all the available roles who can be granted permission to access the folder. Click Save to apply changes.
When a role is allowed access to a folder, all resources within the folder will be accessible to this role. The implication of this rule is that if a role is explicitly allowed access to a service and later the same role is allowed access to the service's parent folder, then the role is able to access the service because of an implicit allow rule.
Consider a secured ArcGIS Server system that has one role named Analyst defined. The folder and service structure on this ArcGIS Server system is depicted by the following diagram:
 |
The table below illustrates the effect to the role's access privileges as successive changes are made to the security configuration.
Change to security configuration for role Analyst | Access privileges for role Analyst |
1. Revoke permissions on all folders and services to the role. |
|
2. Grant the role access to Service 2. |
|
3. Grant the role access to Root folder. |
|
4. Revoke access to the Root folder. This will remove all existing permissions set on folders and services contained within the Root folder. |
|
メモ: Setting permissions on services
Permissions on services follow the continuous inheritance model. A service will inherit permissions from its parent folders when it is created and continue to do so unless explicit permissions are set on it. The administrator can explicitly set different permissions on the service, in which case the service will break its inheritance.
You can set permissions on a service by going to the Services panel in the Manager, selecting the particular service listed on the page, and clicking the Service Permissions icon. A dialog box appears that lists all the roles that currently have permission to access the service along with a list of all the available roles that can be granted permissions to access the service. On clicking Save, the changes are applied to the system.
メモ: Inheriting and overriding permissions
Permissions for a folder are inherited by services within the folder. For example, if you allow a role access to a folder, all services within the folder will also be accessible to this role. The permissions dialog box for each Web service will show the allowed role, along with other roles that you have added, if any. Folders also inherit permissions from their parent folder.
You can remove roles that a service inherits from a folder. To do so, open the permissions dialog box for the service, select the role, and click the left arrow button. This will cause that role to not be permitted access to the service. Since a single user may be assigned to multiple roles, role-based access must be carefully managed.
If permissions for a folder are edited, any changes to role permissions are reapplied to all services within the folder. This will overwrite any changes made to those roles for individual services. If you remove a role from the permitted list for the folder, that role will no longer be permitted access to any services within the folder. Similarly, if you add a role to the folder's permissions list, it will be allowed access to all services in the folder.
Overwriting permissions in child folders and services
When setting permissions for folders, you may see this message when you click Save:
"One or more of the roles you are changing permissions for already has a permission setting in one or more services or folders inside this folder. If you continue, the permissions settings for these roles in child services or folders will be inherited. Do you want to save these changes?"
This message means that you are adding or removing a role that already had explicit permissions in one or more services within the folder, or in a child folder if editing permissions of the root folder. If you proceed, all rules for that role in child folders and services will be removed, and the child folders and services will inherit permissions for that role from the folder.
For permission changes on the root, the message may warn of a more significant change. Suppose you add permissions for a role to a child folder but remove the role's access to a service within the folder. Later, you add permissions for the role to the root folder. You receive a warning because, if you continue, the service within the child folder will now allow access to the role, when previously, access was not allowed.
If you receive this warning when editing permissions of the root folder and are not certain of how the changes will affect access to services, you should cancel the warning message and examine the permissions of child folders and services. You may need to follow up the permissions change by then reapplying rules to child folders and services to produce the desired security configuration.
If you have added or removed more than one role while editing permissions, the message may mean that multiple roles are affected. You may want to examine the permissions on child folders and services to ensure that you are not overwriting permissions you want.