Richard Unger wrote:
A filter is a powerful way to do the authentication, but I think the basic problem is more where the users are stored (ie who's in charge?):
a) Slide stores the users on the slide file system (a solution I personally find horribly ugly)
Why that?
It's ok (and more or less neccesary for ACL stuff) for slide to show the users in the webdav 'file system', but it can't actually store them there - otherwise you lose any chance to use an external authentication database (LDAP, etc.).
-> Either each containser needs a wrapper to access the users
-> Or container based authentication is dropped, and security has to be handled by slide
b) Slide gets the users from the container
-> How to store additional properties (such as group membership) not directly supported by the container but required by webdav?
If you examine what's going on I think there is a basic mismatch between the servlet security model (which has users and roles) and webdav's (which also seems to have groups). It woudl seem therefore, if we want to be true to the spec and support groups (and any additional properties webdav users may have) we should just drop the idea of container based authentication until the security concepts better match and do the authentication ourselves. A filter is a good way to do this I think.
I thought groups match roles, so there is no mismatch, is there?
They're somewhat similar concepts, but they don't match. Most notably, a group can have its members enumerated. A role cannot. WebDAV ACL compliance requires groups (given this distinction). You can pretend they're the same, and just not support some of the live group properties in the ACL spec - it works ok, but isn't ideal.
There is one thing to consider though: Large computing environments typically will already have established user structures stored in LDAP or databases. Portal servers and reverse proxies use authentication tokens to pass logins around clusters of servers, and this requires container based authentication. Can we drop compatibility with all that?
Do not see why we should. We could use web container managed authentication when we access Slide over the webdav tier and direct authentication when accessing Slide directly over its API, right?
This isn't very neat - authentication is best done in one place, not optionally in multiple places. This also makes dealing properly with authorisation hard - you need to have them pretty closely mapped, and this is really hard with the servlet security model (which isn't sufficient for the authorisation part of this problem).
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
