DMA: Authentication and Authorization

%To:	Jon Radoff at NovaLink
%Cc:	Web DAV
	DMA Tech at AIIM
%Re:	DMA Authentication and Authorization

Watching the to-and-fro on this problematic area has been fascinating.  I 
thought it might be useful to relate what we ended up with in DMA 0.9 (the 
current trial-use specification), and what we think we accomplished with 
that.

1.	First, DMA only has a programmatic interface, and has no specified 
on-the-wire protocol, so there are different opportunities.

2.	Secondly, DMA provides for authentication, but is silent on 
authorization.  That is, there is no well-known, prescribed way to specify 
authorizations.

3.	The authentication model is from ODBC.  An object that requires 
authentication for usage has an authentication interface.  This interface 
has an authenticate method that involves passing in a string of name-value 
pairs that are intended to establish an authenticated access.  A null 
string is a good starting point.  The authenticate method either reports 
success, and the client has been authenticated as having a pariticular 
authorization for access to otherwise-restricted methods of the object.  If 
the authenticate method reports "failure", it also returns a string 
specifying the name-value pairs for which values must be supplied for 
authentication to succeed.  This interesting interface was valuable for us 
because it does not involve direct user interaction.  The ODBC negotiation 
sequence is also stateless and the responses can also offer locale-specific 
strings that may be useful in prompting an operator for the values of 
authorization parameters.  It is also possible to operate this interface 
silently without operator involvement, another attraction for scripting and 
batch operation.

4.	In various methods on objects, ones requiring authentication or ones 
derived via authenticated use of objects, it is possible to learn that an 
operation is not authorized.  This is typically a policy response by a DMA 
Document Space, the DMA abstraction for a collection and the mechanisms 
that operate it.  Objects might be read only, or not authorized for update 
access, or whatever.  So by having authenticated the access to an object, 
authorizations can be enforced with regard to that particular authenticated 
access.

5.	How authorizations are carried in collections, how they might show up as 
properties on objects, and what the mechanisms is for specifying 
authorizations is not defined in DMA 0.9.

6.	In particular, when a new object is introduced (assuming that the 
authenticated access is authorized for that), there is no specified way to 
establish the authorizations on the new object.  They must be established 
by policy of the Document Space based on the authenticated access (which 
might have an associated default authorization) and/or by the specification 
of values for properties that determine authorization as part of an 
established protocol that the Document Space implementation is a party to.

WHERE THIS LEFT US

7.	There is a simple protocol for authentication, based on a scheme in 
ODBC, that ensures the foundation for any 
Authentication-Authorization-Accounting protocol is in place.  This scheme 
allows existing authentication schemes to be used and mapped through the 
DMA API and any sufficiently-secure middleware.

8.	Although there is no protocol or model for expressing and manipulating 
authorizations in the DMA 0.9 model, (7) is sufficient for an authenticated 
access to be subject to authorization policies implemented in DMA Document 
Spaces.

9.	What we have avoided is invention of an user and identification model by 
which authorizations are to be expressed.  The assumption is that existing 
models can be mapped through DMA, especially in legacy situations, and 
people can set to work coming up with agreements, supplemental protocols, 
and extensions for authorization (and improved authentication across 
heterogeneous systems) as a separate activity from the core provisions of 
DMA.  We would prefer to borrow from a broader approach to authentication 
and authorization and simply agree on its expression via the DMA 
interfaces, methods, and object properties.

10.	It seems we are pretty satisfied that the foundation that we have 
allows a program such as (9) to be carried out, whether or not it is always 
pretty.  Also, we have a versioning and revisioning model -- involving 
interface and property registration -- that allows extensions to be 
introduced and normalized over time.  This is an avenue for experimental 
introduction of proposed approaches and development of  adherence over 
time.

11.	I do not want to leave the impression that this is a particularly 
satisfying outcome.  What it does provide is a way for us to confine the 
early work on DMA and avoid having to solve problems not of our own making 
and for which DMA is not necessarily the place to solve them.  We didn't 
see ourselves as having either the subject-matter expertise or chutzpah to  
 propose a global solution to AAA and end up with 
yet-another-authentication-and-authorization protocol.  In other places 
closer to the heart of document management we are more brazen.  But not 
here.

12.	I would expect that as DMA systems are deployed we will see a demand 
for a more-disciplined attach on this area, with at least enough promotion 
of agreements so that the handling of versioning check-out and check-in 
cases can be tied to authentication and authorization in a clear way.  This 
has always been the place where our detached view is closest to breaking 
down, because of the need to tell who owns a check-out, who can revoke it, 
etc.  So it is pretty clear that a Document Space will have to expose 
something here, even if we ducked the issue in the DMA specification.   Now 
that we are in trial use, I expect that more clarity will emerge in the 
next 2-3 months, and running code and worked out agreements among 
repository vendors and enterprise stakeholders may well rule on the matter. 
 Also, users will not tolerate not having authorization control at least in 
conjunction with administrative processes.  There are simple practical 
requirements that implementations must support even if there is no 
consensus on a uniform approach for codification in the DMA specification.

SO WHAT ABOUT WEBDAV?

13.	I don't have a position with regard to WebDAV's addressing this area. 
 I just wanted to share our experience.  I'd be surprised if we couldn't 
appropriate any WebDAV scheme that comes up, if it happens to go farther 
then where DMA 0.9 has gone and the user community concludes that to be 
close enough for having more completeness in DMA.

14.	On the other hand, when we looked at this for DMA, we had the advantage 
of the Shamrock coalition's earlier efforts to provide for user models and 
authorization in the Shamrock repository specification.  An appreciable 
part of the Shamrock specification was devoted to this particular topic and 
it leaked into a lot of places.  Not only was that a big job (if you were 
counting function points or some other complexity factor) but it wasn't 
particularly satisfying, as far as I could tell, because there is always 
the question about how it fits into whatever enterprise scheme a particular 
customer population has implemented or is leaning towards.

Dennis E. Hamilton
Xerox Document Management Systems Architecture

----------
From: 	Jon Radoff[SMTP:jradoff@novalink.com]
Sent: 	Monday, May 12, 1997 20:57
To: 	w3c-dist-auth@w3.org; jradoff@novalink.com
Subject: 	Access Control Draft

Received on Monday, 19 May 1997 12:42:42 UTC