13.5 Standardization Challenges

Standardizing access control has been particularly difficult. It was known to be a difficult problem from the start. Dan Connelly asked the mailing list in July 1996, "This has been an open problem in distributed systems for tens of years. We don't expect to solve this long-standing problem, do we?"

It's not that the basic functions for changing access control settings are that complicated. They are rather simple. There are significant barriers to defining an interoperable system because of the way existing systems work. Existing systems can't be ignored when it comes to access control, because WebDAV is often built on top of or to extend existing systems, and it's important for access control information to be consistent and consistently enforceable.

13.5.1 User Databases

Every company with more than a handful of employees has some kind of user directory or user database, if only a set of Unix accounts on a server. Many secondary user databases exist as well. Popular Web sites such as The New York Times require users to log in to access certain pages. An access control system for WebDAV must not ignore these user information databases.

LDAP servers are increasingly being used as a central and authoritative repository to store and retrieve principal information for an organization. LDAP was designed to provide light weight access to a directory of users, groups, and other entities. An LDAP directory has a number of entries, some of which may correspond to principals.

Although LDAP is a standard protocol, the LDAP data model can vary. There may not be a standard list of attributes (those are LDAP's analog to properties) that a common object such as a "group" must have. An Informational IETF standard [RFC2798] defines standard attributes for a user object, and this standard seems to be gaining adoption at Microsoft and Sun.

LDAP URLs are standardized [RFC2255]. An LDAP URL begins with the ldap scheme, identifies the host and the port just as HTTP URLs do, and then contains the distinguished name for the directory entry. This definition of an LDAP URL isn't complete, but it's enough for us to be able to name principals with LDAP URLs. For example:

 
 ldap://ldap.example.com/cn=Alice%20Wetherill,dc=example,dc=com 

In this example, the common name (cn) for the entry is Alice Wetherill (note that the space character is commonly escaped as %20) and the domain is example within the domain com.

Because of the way WebDAV ACLs require user and group information to be exposed as WebDAV resources with WebDAV properties, client software doesn't have to support LDAP (or any other protocol besides WebDAV) to do basic access control operations. This is critical to keeping the standard simple enough so that client software can implement it.

A WebDAV server may connect to an LDAP server and retrieve information on behalf of clients, transforming LDAP attributes into WebDAV principal resource properties. In fact, a WebDAV server could theoretically expose any user directory that way.

13.5.2 Multiple Access Protocols

WebDAV is usually not the only way that resources in a repository can be accessed. In Web servers such as IIS 5.0 and Apache, resources are primarily available over HTTP and WebDAV. However, the same resources can also be accessed directly on the file system. In an intranet, files shared on the Web are often shared on a networked file system at the same time. In the Internet, files may be accessible via HTTP and FTP at the same time. Exchange 2000 supports a handful of ways to get to each resource: An email may be available through WebDAV, MAPI, SMB, and IMAP.

Such multiprotocol support is wonderful for end users who have the freedom to choose the most appropriate client software for each task. However, it's a nightmare to administrators and implementors who must ensure that access is consistent for each protocol. If access to the resource is denied, it must be denied over all access protocols; otherwise, access control becomes quite unmanageable. It's too complicated to set access control separately for each access protocol, because the models may be different and it's too easy to make mistakes, allowing an operation on one protocol when the corresponding operation is denied on other protocols.

The IIS 5.0 approach to unifying access control over several protocols is to use the underlying file storage system to control access. The file index.html may ultimately be stored as a file somewhere on the C:\ drive of a Windows-based server, and Windows access control can be used to prevent unauthorized client access. Then every service that allows any remote or local access to index.html (the FTP server, the Web server, and SMB) must use those permissions. The service authenticates the user to identify them, and then provides that identity to the file system. The file system must trust the server software to do this securely and honestly. This also requires that each principal needing access has an identity known to the file system.

If multiple protocol access is not a goal, then it's possible to lock down WebDAV resource access much more tightly, as Xythos WebFile Server does. When only one service controls access to files, then access control policy is more likely to be consistent. If files are stored encrypted on the file system or in a database, then even local access to the computer where the files are stored may be possible without compromising the security of the WebDAV resources.

An intermediate model is illustrated by mod_dav. Files and collections are stored as files and folders in the file system, and metadata is also stored as files in the file system. File system ACLs may be very restrictive. The administrator is expected to lock down the file system access so that even though those files are theoretically accessible via NFS, other processes can't readily alter Web content or metadata. Instead, mod_dav obeys Apache permissions stored in configuration files. To support access control, mod_dav might expose the Apache permissions through the WebDAV ACL model and modify the permissions on disk.

Because multiple protocol access is a reality in many situations, the designers of WebDAV ACLs had to define a flexible set of privileges, shown in Section 13.2.4. Theoretically, the privileges defined can be customized so that the underlying operating system can enforce the privileges if that model is chosen.



WebDAV. Next Generation Collaborative Web Authoring
WebDAV. Next Generation Collaborative Web Authoring
ISBN: 130652083
EAN: N/A
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net