This seems right when considering Jackrabbit's current approach to authentication. Of course, it would be nice if Jackrabbit/JCR-170 would provide the option for you to handle authentication yourself (before invoking Jackrabbit), at which point Jackrabbit would interact with your security via some interface (such as Ben explained in his original message to the Jackrabbit list). As it stands now, I think the two options you describe are all that we have: 1) Authenticate with Acegi up front, passing a special javax.jcr.Credentials to Repository.login(), which would then be passed to a dumb Acegi-provided JAAS LoginModule. Well, maybe not quite so dumb, it could validate the authentication I suppose. Or 2) Extract whatever contextual authentication information is available (whether it be username/password from Basic auth header or digest from digest auth header - etc) using some flexible Acegi provided extraction mechanism, place those into a specially crafted javax.jcr.Credentials, which are then passed to Repository.login(). An Acegi provided JAAS LoginModule would then interpret and authenticate the credentials appropriately (handling different cases, such as basic and digest).
I agree that the WebDAV adapter shouldn't deal with authentication under any case. Acegi should "surround" the adapter in such a way that the adapter has nothing to do but pass in opaque authentication information from Acegi to Repository.login(). In both cases outlined above, Acegi could provide the WebDAV adapter with something opaque enough that the adapter should have no knowledge of how the authentication is implemented. It would wrap this opaque information into a special javax.jcr.Credentials and pass it through (that is, if we decide that Acegi shouldn't do the wrapping). I wonder if it would be possible for the adapter to even have no knowledge of Acegi? I did a *real* quick skim of BasicProcessingFilter, and it appears that it authenticates whatever information it finds in the basic header. This is probably true for other filters (such as digest). Since #2 would require a two step process (extraction of auth information would be separate from authentication), probably the path of least resistance at the moment would be option #1. Though, the path of least resistance does not always equal the best path. :) With option #1, the principal would already be authenticated by the time your WebDAV servlet is invoked. You would then package up the already authenticated principal in such a way that an Acegi provided JAAS LoginModule would recognize it and handle it accordingly. I have never looked into JAAS support with Acegi, so I don't know where that stands right now. - Andy On Wednesday 16 March 2005 09:37 am, Brian Moseley wrote: > nope, you have the gist of the problem. JCR expects to > authenticate the request itself (Jackrabbit does this via JAAS). > > i guess one approach could be to have Acegi Security do the > authentication upstream and then have the WebDAV adapter > pass to Repository.login() a javax.jcr.Credentials > implementation that carries the authenticated principal > along to a dumb JAAS LoginModule. > > alternately, the Credentials implementation could just > contain what ever contextual information is necessary for a > slightly smarter LoginModule to extract the authenticated > principal from the context. > > in either case, the WebDAV adapter itself should have to do > no more work than finding the credentials in a well known > place and handing them to the repository. it should be the > job of the security filters and the LoginModule to do all > the dirty work. > > sound right? ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Acegiwebdav-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegiwebdav-developer
