Within an Access Control List (ACL), you define the access privileges for specific ArcIMS services.

Setting these attributes allows you to:

• Set usernames and passwords for accessing services.
• Define the levels of access to your Metadata Service.
• Limit use to designated client machines only (by IP address).
• Set an expiration date and time for a user.
• Deactivate a specific user.
• Restrict use of specific ArcXML elements.

The following attributes are available. In the case of an XML file-based ACL, these attributes are specified with the USER tag in the file. With a JDBC-based ACL, these attributes define the column names in the user table and permissions table in the database.

The attributes name, password, and services grant access to services. The attributes active, expiration, forbiddentags (ftags), roles, and trustedclients (tclients) place additional restrictions on accessing the service through the username.

Name
The username. Only one username can be specified per USER tag in a file-based ACL or record in the user table for a JDBC-based ACL. Usernames are case-sensitive. Use an asterisk (*) to indicate all clients can access the service without entering a username. This attribute is required.

<USER name="user1" password="password1" services="Map1, Map2" /> <USER name="*" services="Map3, Map4, Map5" />

password
The password for the specific username. Only one password can be specified per USER tag in a file-based ACL or record in the user table for a JDBC-based ACL. Passwords are case-sensitive. This attribute is required, except when the username is an asterisk (*).

Passwords can use letters and numbers. In addition special characters can be used with the exception of the percent sign (%), ampersand (&), less than symbol (<), and double quotes ("). If any of these four special characters is used in a password, the entire ACL becomes invalid.

services
The service name. This attribute is required. For a file-based ACL, use a comma to separate the list of service names. The names listed should match the case of the service names created in Administrator. Use an asterisk (*) to indicate a user, such as an administrator, who should have access to all services.

<USER name="user1" password="password1" services="Map1" /> <USER name="user2" password="password2" services="Map2,Map3, Map4" /> <USER name="superuser" password="superuser" services="*" />

For a JDBC-based ACL, add one record to the permissions table to associate a service with a particular username and password. An asterisk (*) cannot be used here.

roles
Use this attribute to govern the level of access a user has to a Metadata Service. The roles attribute can be set as follows:

• metadata_browser
- enables browsing of all public metadata documents of a Metadata Service (default if not specified).
• metadata_browser_all
- enables browsing of all public and any private documents published to the Metadata Service.
• metadata_publisher
- enables publishing to the service.
• metadata_service_author
- enables creating metadata for services. You apply this parameter to those Feature, Image, and ArcMap Image Services that you want to create metadata for. You may then subsequently publish this metadata to a Metadata Service.
• metadata_administrator
- enables administration of database, i.e. ability to reset the metadata tables in the database.

The roles are hierarchical, and each of the roles encompasses the permissions of the lesser role. For example, a metadata_publisher can also browse and a metadata_service_author can also publish and browse. Users access this functionality through ArcCatalog by specifying their ACL login in the connection dialog.

Metadata roles must have a specified user. Anonymous access using an asterix (*) is not allowed.

In this example, all users can see the BigMap1 Image service and can search and browse the Metadata Service, 'MyMetadata', without entering a username and password. However, additional access to the MyMetadata service and permission to create metadata for the ?BigMap1? service is restricted. Any other Image, ArcMap Image, and Feature Services present on the ArcIMS server will be inaccessible if they are not added to the services list for the user ?*?.

<USER name="*" services="*" /> <USER name="publish" password="publish" services="MyMetadata" roles="metadata_publisher" active="1" /> <USER name="author" password="author" services="MyMetadata,BigMap1" roles="metadata_service_author" active="1" /> <USER name="administrator" password="administrator" services="MyMetadata" roles="metadata_administrator" active="1" />

When publishing metadata describing an Image, ArcMap Image, or Feature service to a Metadata Service, the user who authors metadata should also publish the metadata. Otherwise, an author who later updates the metadata would not also be able to republish the updated metadata to the Metadata Service. Because the author does not own the original metadata document in the Metadata Service, the author would not be able to replace the original document with a new one. If you explicitly list services for each metadata author in the ACL, be sure to include the Metadata Service in the list of services each author can access.

active
Indicates whether the username is active. Set active to 0 to disable the user from accessing the restricted service and any integer greater than 0 to enable client access. When active is omitted, the username is active. The following line disables the username in a file-based ACL. This attribute is optional for a file-based ACL, but required in a JDBC-based ACL.

<USER name="duck" password="quack" services="DuckHabitats" active="0" />

Tip: You could use this attribute as a counter to indicate the number of days a client can access a restricted service. You must develop an application to decrement this value and, when using a file-based ACL, stop and restart the servlet engine to update the attribute.

expiration
Indicates the date and time when the username expires and access to the services is no longer available. For example, you could use this attribute to create a subscription-based service, where the user is given access to a service for a limited time. The expiration value must include hours/minutes/seconds. This attribute is optional.

<USER name="duck" password="quack" services="DuckHabitats" expiration="10/16/2005 11:24:30" />

forbiddentags (ftags in JDBC-based ACL)
Use forbiddentags to prohibit clients from sending specific ArcXML elements. Common elements to forbid are GET_FEATURES, GET_EXTRACT, GET_GEOCODE, GET_LAYOUT, GET_METADATA, PUBLISH_METADATA, GET_RASTER_INFO, and WORKSPACES. By forbidding these requests, you can limit the functionality of the service since the requests are prevented from being sent to the ArcIMS Spatial Server. This attribute is optional.

While you can forbid any of the above, the list below identifies the typical uses for Image and Feature services.

Image Service - forbid GET_FEATURES to disable queries like identify and the query builder. Forbid GET_GEOCODE to prevent geocoding. Forbid GET_EXTRACT to protect your data and prevent download in shapefile format. Forbid WORKSPACES to present users adding data from unauthorized directories in dynamic layers.

Feature Service - forbid GET_GEOCODE to prevent geocoding.

Use a comma to separate the list of forbidden elements. An asterisk (*) is an invalid value.

<USER name="guest" password="guest" services="tributaries" forbiddentags="GET_FEATURES, GET_GEOCODE, GET_EXTRACT"/>

trustedclients (tclients in JDBC-based ACL)
A comma-separated list or range of IP addresses of the machines that can access the services. This attribute provides an additional level of security by requiring the username and password to be entered from a specific set of machines identified by their IP addresses. A client will not be able to access the service with the username and password unless they do so from one of the listed machines. This attribute is optional.

You can use wildcards (*) in this attribute, whether the attribute is one IP address with a wildcard, a comma-separated list with one or more wildcards, or a range of IP addresses with one or more wildcards.

In the following example, a comma-separated list of IP addresses is given. The first is a client accessing from 198.102.62.1. The second is any client accessing from an IP address that starts with 198.102.63.:

<USER name="user1" password="password1" services="Map1,Map2" trustedclients="198.102.62.1,198.102.63.*" />

In the next example, a client can access from a range of IP addresses. A client is valid if the IP ranges from 198.102.62.1 through 198.102.62.24.

<USER name="user1" password="password1" services="Map1,Map2" trustedclients="198.102.62.1-198.102.62.24" />