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?


-> 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?


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?


Also, passing the security on the container is an awfully nice way to pass the buck for a tricky piece of code, not to mention that we'd be reinventing the wheel if we did it ourselves.

Perhaps we can find a good solution that satisfies both worlds, but it is tricky, and to me it looks like we should drop the parts of the security from slide that aren't part of the Servlet 2.3 spec...

Maybe I still do not quite understand... Why dropping web container managed authentication for Tomcat. It works, so let's keep it...


Oliver



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to