Quoting Unico Hommes <[EMAIL PROTECTED]>: > > > Oliver Zeigermann wrote: > > > > > > Unico Hommes wrote: > > > > > > Oliver Zeigermann wrote: > > > > > > <snip/> > > > > > >>>Sorry, but I don't think all this should be Slide's concern at all. > > >>>What does Slide do ATM? > > >>> > > >>>1. It's got a core repository and a WevDAV adapter in the form of a > > >>>servlet. The way this is distributed in the servlet world > > >> > > >>is through a > > >> > > >>>web archive. > > >> > > >>I do not see how the web container can do the authentication > > >>stuff when > > >>Slide is deployed as a single "war"? Do you? > > >> > > > > > > > > > No, but this would have to be configured differently for different > > > servlet containers anyway. If you want that to work out of > > the box you > > > could consider a ServletFilter as an alternative. It would have the > > > added advantage of being container independent. > > > > I do not see how the web container would do the authentication then. > > Could you explain your ServletFilter idea a little bit more. > > I'd really > > appreciate that :) > > > > I'm sorry, I see my wording wasn't very clear. I meant to say not to use > container based authentication at all because that will be server > specific. The solution for cross-container, out-of-the-box > authentication is to provide a servlet filter for that does all that. >
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) -> 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. 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? 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... Richie > Now, I think this isn't a perfect solution. More code to write and > maintain etc. So I think you have a point when you realy want to provide > out-of-the-box authentication. I don't know if Slide should provide > this. Maybe. Still, it doesn't have to be Tomcat. > > Unico > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------- This mail sent through the ungerground webmail system --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
