AFS Administration Web Service

The AFS Administration Web Service will provide a web services front end for common AFS operations requiring adminsitrative AFS access. The service will be configured such that it enforces authentication and authorization for clients, and restricts their ability to work with AFS space appropriately.

Requirements

1. The service shall provide the following functions as a web service:

   • Volume Inspection

   • ACL Inspection

   • ACL Setting

   • ACL Clearing

   • Quota Inspection

   • Quota Setting

   • Site Volume Creation

     • Volume Creation

     • Mount Point Creation

     • ACL Setting

     • Quota Setting

   • Volume Creation

   • Mount Point Creation

2. The web service shall use SOAP as the packaging protocol.

3. The service shall provide WSDLs for all exposed functions

4. The service must implement authentication and authorization for web service clients

   1. In the first phase, IP-based security shall be acceptable

   2. In later phases security must be upgrade to Certifcate or Kerberos based security.

5. The service must restrict AFS actions on volumes based on checking authenticated user ids against ACLs

6. The service must generate appropriate AFS volume identifiers, guaranteed against collision

Analysis

This service will wrap AFS administration functions that can only be invoked by the afs administrator account for use by multiple external applications. Given that these administration commands provide sweeping control over AFS resources, a rigorous authentication and authorization service must be developed.

Authentication and Authorization

In order to access the service, the connecting client must present some authentication credentials. Once authenticated, authorization decisions will need to be made about the command invoked as well as its parameters.

Authentication Phase 1 - IP Security

In the initial implementation IP-based authentication will be implemented. In this solution, the ip address of incoming requests will be compared against a database of valid IP addresses. If the IP matches one in the database, the request will be allowed, and the AFS user name will be set to a user name accompanying the registered IP address. IP-masquerading is the most likely method of exploit for this type of security. This risk can be reduced by putting the client and server applications behing a firewall or by having all servers inhabit a private network using a private IP address space.

Authentication Phase 2 - Certificate / Kerberos Security

Authorization

A successful service authentication will result in a valid AFS user name. In all cases, the authenticated AFS user name will be checked against the ACL for the target or containing directory to determine if the user is authorized to perform the requested action.

Site Volume Initial ACL Settings

1. Course Sites (e.g. /afs/.ucdavis.edu/app/sakai/class/^200603^/^UBW101001^/smartsite)
   Course sites involve volume sharing among multiple sakai instances. Therefore, the volume creation process must add all sakai instances to the ACL when creating a volume. Realistically, this case will need to be detected in the path to the volume. Note: The Site Volume creation process must create the Term volume if necessary. The ACLs for the class/ directory should be set to include all web service users in order to support this.

2. Project Sites (e.g. /afs/.ucdavis.edu/app/sakai/project/smartsite/^year-month^/^siteid^)
   Project sites are split among instances before the volume level. Therefore, inspection of the ACLs for the containing volumes should reveal what instance should be on the ACL list. Note: The Site Volume creation process must create the year-month volumes if necessary. The ACLs for the instance directories should be set correctly such that the application can create volumes there.

3. Other Tools (e.g. /afs/.ucdavis.edu/app/sakai/misc/melete/^smartsite^/)
   Storage for tools not using the Sakai Resource framework are split among instances before the volume level. Therefore, inspection of the ACLs for the containing volumes should reveal what instance should be on the ACL list. Volumes in this space will be created by hand, and therefore should not be necessary.

WSDL Specification

• GetVolumeInfo(path) - Returns information about volume at path

• GetACL(path) - Returns ACL for path

• SetACL(path) - Add authenticated AFS user to ACL if not already there

• ClearACL(path) - Removes authenticated AFS user from ACL

• GetQuota(path) - Returns Quota and free space for path

• SetQuota(path,newquota) - Sets Quota to newquota for path

• CreateSiteVolume(path,quota) - Creates volume and mountpoint at path, with quota set to quota, and appropriate ACL

• CreateAFSVolume(volname) - Creates volume

• CreateMountPoint(path,volname,quota) - Creates mount point at path, attaches volume to mountpoint, assigns quota, and appropriate ACL