djencks, I am not sure what the client side of a jaspi api would look like, can you give an example of what it would be doing?
from my perspective what we need to wire up in mercury right now is some generic security api that something like maven can inject with the goop in setting.xml meshed with repositories tags so it can select the right 'security realm' based on hostname, returned realm, or whatever the case may be. I know you have done a mess of jaspi work on a jetty trunk branch...am interested in how that maps back to client type stuff :) client side is a pain jesse On Fri, Jul 18, 2008 at 2:16 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Jul 17, 2008, at 4:26 PM, Jesse McConnell wrote: > >> hey all, >> >> I have been working on the jetty-client in the jetty project over in >> codehaus which is the library mercury uses that is doing the >> asynchronous retrieval and deployment of artifacts. Greg Wilkins and >> I have recently been increasing the functionality of the jetty-client >> and we are getting to the point where we need to do a bit more >> integration with mercury, namely in the area of security, >> authentication specifically. We have ssl support and cursory webdav >> support for creating directories on put operations if webdav is >> enabled server side in places and all of this shares the same async >> nio framework that jetty uses very successfully for scaling to very >> large numbers of connections. It is pretty nice and small as well. >> >> Anyway, the security api in jetty-client is still open and somewhat >> malleable if we add some additional options, but it ought to work for >> what is needed here. The specific integration bit needed right now in >> mercury is in mapping username/password credentials to the relevant >> host. In jetty-client we have this broken out by the security realm >> that the target host replies with in the authentication request header >> but that doesn't necessarily apply in maven-land. I am not sure what >> sort of api we ought to have in mercury for this, but the jetty-client >> allows for extending a couple of interfaces which allow you to setup >> your own security realm and mapping solution. It should also be able >> to support simple things like adding a realm that would prompt the >> user for username/password and then cache that for future use by other >> connections in that batch. > > I hope this interface can be made JASPI friendly. There's no explicit http > client profile in jaspi and presumably the client side authentication has > the same kinds of problems as the server side authentication but I suspect > that we can work something out that is both efficient and spec compatible. > > thanks > david jencks > >> >> >> Anyway, I am interested in hearing how folks want to address this in >> mercury so any thoughts are more then welcome. I am not sure how much >> mercury has been discussed on the dev list up to this point but I am >> assuming that most of you have an inkling of what the goal of mercury >> is...if not ask away and someone will chime in :) >> >> cheers, >> jesse >> >> -- >> jesse mcconnell >> [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
