Richard Unger wrote: > > > Quoting Unico Hommes <[EMAIL PROTECTED]>: > > > > >
... > > > > > > 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) > > > > It's due to the fact that principals in DACL are exposed as regular > > WebDAV resources. When I first learned about this approach > I found it > > novel but I think its quite nice. > > > > Its actually part of the spec? I can't access it right now, > so I could not check. I still find it ugly. But like I said, > that's subjective. > Hmm, checking... here's a relevant section: ".. servers implementing this specification MUST expose principal resources at an http(s) URL, which is a privileged scheme that points to resources that have additional properties, " ... "Although an implementation SHOULD support PROPFIND and MAY support PROPPATCH to access and modify information about a principal, it is not required to do so." So ok, I guess not really part of the spec. > > > -> Either each containser needs a wrapper to access the users Or > > > -> container based authentication is dropped, and > security has to be > > > handled by slide > > > > > > > I've been looking into JAAS LoginModule functionality and > noticed that > > both Jetty and Tomcat provide JAAS adapters for their respective > > realms. I have to look into it more - especially regarding callback > > mechanism - but it may be the container agnostic way of providing > > container managed authentication. > > > > That sounds really good. I will look into this. > > > > 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? > > > > > > > This is not an option. Slide needs full control over principals to > > support WebDAV access control. > > > > I agree. > > > > > > > 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 don't see the problem here. A container provides the caller > > principal through request.getPrincipal() method and Slide > uses it as > > the credentials for its operation. Internally, because Slide knows > > about the principal - after all it provided it to the > container - all > > group-, role-, whatever- checking is done without the the > need for any > > additional calls to the servlet API. > > > > With this I agree. There is no problem with slide using the > principal obtained from the container, in fact it should. > > > > 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? > > > > > > > IIUC, not so. Write a LDAP/DB/etc Slide store implementation and > > define it to match /users scope. > > > > This is a good solution if the spec requires the users be > exposed as resources, I suppose. > I need to get a look at the > spec to see what is actually required, I can't access it right now... > > > > 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. > > > > > > > Yep. This is what convinces me to Oliver's point. > > > > I don't see what you are saying here... Security is a tricky > area, right? The more code involved in checking, storing, etc > users, the worse. > No, I am agreeing with you (and Oliver) that keeping container managed authentication is a good thing after all. Cheers, Unico --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
