RE: Authentication and Authorization
I like this approach. If you can come-up with a scheme for authentication and a list of the operations which we would like to control for any given resource or set of resources then the authorisation issue could simply be solved by authenticating and attempting to execute an operation or authenticating, requesting the operations which are allowed for a resource and the executing an allowed operation.
Modifying the authorisation is then simply an operation like any other.
From: Dennis E. Hamilton[SMTP:email@example.com]
Sent: Montag, 19. Mai 1997 17:35
To: 'Jon Radoff at NovaLink'
Cc: 'Web DAV'; 'DMA Tech at AIIM'
Subject: 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
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
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
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
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
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
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
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:firstname.lastname@example.org]
Sent: Monday, May 12, 1997 20:57
To: email@example.com; firstname.lastname@example.org
Subject: Access Control Draft