ACL report problem: principal-property-search

I try to execute a principal-property-search report method on the web-dav server 4.1 on Win2000. The request looks like this:
-----
REPORT /taminowebdavserver/administration/security/users HTTP/1.1
Content-type: text/xml; charset="UTF-8"
Host: hw0272:80
Content-length: 295
Depth: 0
Authorization: Basic bWR1bGlzY2g6bWR1bGlzY2g=

<?xml version="1.0" encoding="utf-8"?>
<D:principal-property-search xmlns:D=“DAV:”>
<D:property-search>
<D:prop>
<D:displayname/>
</D:prop>
<D:match>md</D:match>
</D:property-search>
<D:prop>
<D:displayname/>
</D:prop>
</D:principal-property-search>
-----

I get the following error:

HTTP Status 400 - Bad Request: Invalid child [Namespace: prefix “D” is mapped to URI “DAV:”]:match of element [Namespace: prefix “D” is mapped to URI “DAV:”]:property-search

The request syntax is from the ACL specification. Why does it not work on the web-dav server?

Thanks
Martin

The ACL specification is still only a draft. Right now, the Tamino WebDAV server currently implements an older draft (not the latest one, anyway - from memory, I think it implements draft-ietf-webdav-acl-07 or -08).

The spec changed quite significantly between that draft and the current one.

The older drafts are still available, if you want to write software to work specifically against the current version of the tamino webdav server.

Thanks Michael,

that was the reason. Now the report works. But I have a new problem now: the server response has status code 200. I think it should be 207 (mulit-status). Or am I wrong?

Yes, this should probably be a 207. However, I’d say returning a 200 instead of a 207 (rant about the insanity of multistatus responses removed…) is a relatively minor problem compared with the fact that the ACL implementation is of an expired (i.e. no longer valid!) draft which differs substantially from the current draft (which might itself change significantly before it leaves draft status).

I also found that the ACL implementation currently is too limited to be useful - I could not find any way to set non-inheritable permissions, or any way to map a username to a principal, or any way to manage groups/roles (all of these are possible in non-portable ways not specified by the drafts, but that’s not very useful in writing a webdav client)

Hello Michael,

we have implemented http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.txt. As always, if you implement against a draft, there will be further drafts and the final standard appearing after the release, which may be not compatible.

Currently three authentication mechanisms are implemented (Tamino, OS and LDAP). The mapping between a user-id (from Tamino, OS or LDAP) and a principal (which is a URI) is done by mapping those user-ids into the WebDAV name space (/taminowebdavserver/administration/security/users). The authentication itself is not defined in the ACL standard. The mapping is a convenience function to have an identical set of user-ids and principals. Currently the managing of principals and groups (roles are not defined in the ACL standard) is read-only. Write operations are directly done in the underlying user database (tamino, OS or LDAP). If the WebDAV name space would allow a write operation too (e.g. create or delete a user-id/principal) the server would need to delegate this operation to the underlying user-db system. Would this make sense for your client?

best regards

Juergen

Juergen,

Yes, I understand that it’s not your fault the implementation no longer matches the current draft (it’s just rather unfortunate that the draft changed in fairly major ways after -08). That URL no longer works, by the way - though I did read it some weeks ago when it was available, I think.

I am aware of how the tamino webdav server maps usernames to principals - that’s what I meant when I said “possible in non-portable ways”. This requires very specific knowledge of the particular implementation - a generic webdav/ACL client has no way to find out that a user is mapped to /taminowebdavserver/administration/security/users/username without this a-priori knowledge.

However, the draft ACL specification (I’m looking at -10, I don’t recall whether this was in -08) does give a way to find this out (section 9.4). Without that being implemented correctly, my client cannot (well, it has a tamino-specific hack at the moment - but I don’t want to leave that there) find a principal. (if I’m out of date here and tws DOES now support this, I apologise. It didn’t when I investigated this).

The problems go deeper, however (i.e. there seem to be pretty major problems with the spec in this area as well). Though the principal-property-search REPORT allows you to find a principal based on property matching, there’s no way to guarantee (a particular implementation might - but a client cannot rely on this) that this will return only one principal - there is, fundamentally, NO WAY according to the spec to map from a given user-id (user-id being the most important thing here, since it’s what users authenticate as) to a single principal. Heuristics can give you a best guess, and it might work well in practice, but it’s not really good enough.

The current ACL spec is (by my reading, anyway) also has problems when it comes to groups. Once I have a principal for a given user (with all the difficulties that may entail…), I can find (by using the required DAV:group-membership property) the groups that user is already a member of, but there appears to be no clear way to find out what groups exist, or to get a group principal for a known group name (independently of having a user principal which is a member of that group).

Finally, and probably most seriously, the lack of any way to specify inheritability of ACEs when submitting an ACL request makes the ability to change ACLs completely crippled. Worse - since the ACL method replaces ALL the current ACEs when submitting an ACL request, this means that it is not possible to even correctly preserve existing ACEs where the behaviour is (as in TWS) to set all submitted ACEs as inherited (and there’s no way to find out what the server will do in this case - you have to submit the request and then find out, afterwards, what it actually did).

Sorry for the long post - this isn’t a complaint against TWS (which is generally excellent - thanks!), just a long rant against the incredibly poorly designed (in my opinion) ACL spec.

Mike

Hello Michael,

thanks for your positive statement about Tamino WebDAV Server!

In the acl@webdav.org discussion list there is a recent thread ("[ACL] Identifying a principal") concerning this issue. Perhaps you want to contribute here too.

Concerning the inheritance we had discussion in-house too. In the end we came to the conclusion that most (or all?) use cases would be covered by the inheritance implementation and this would cover the standard. Would you like to post your use-case, you have in mind? The best place would be at acl@webdav.org, so the ACL experts can participate.

Best regards

juergen