Re: artifact retrieval, mercury, and jetty-client
Why is this particular API of interest? Trying to the container security inside G to grab plugins from a remote repository? On 21-Jul-08, at 2:39 PM, David Jencks wrote: On Jul 18, 2008, at 12:28 PM, Jesse McConnell wrote: 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? The basic idea is that, in a client, you'd be calling a authentication context before sending the message to secure it and after receiving the response to validate it. The server can conduct a conversation with the "validate response" part for stuff like basic auth challenges, form auth redirects, etc. The specific methods in ClientAuthContext from the jaspi spec are AuthStatus secureRequest(MessageInfo messageInfo, Subject clientSubject) throws AuthException; AuthStatus validateResponse(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException; The MessageInfo object has the request and response messages accessible inside it. This might not be the ideal list to discuss this in more detail :-) thanks david jencks 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com --
Re: artifact retrieval, mercury, and jetty-client
On Jul 18, 2008, at 12:28 PM, Jesse McConnell wrote: 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? The basic idea is that, in a client, you'd be calling a authentication context before sending the message to secure it and after receiving the response to validate it. The server can conduct a conversation with the "validate response" part for stuff like basic auth challenges, form auth redirects, etc. The specific methods in ClientAuthContext from the jaspi spec are AuthStatus secureRequest(MessageInfo messageInfo, Subject clientSubject) throws AuthException; AuthStatus validateResponse(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException; The MessageInfo object has the request and response messages accessible inside it. This might not be the ideal list to discuss this in more detail :-) thanks david jencks 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact retrieval, mercury, and jetty-client
Jesse, From maven side - I know you've gone through that, but just to reiterate: we have a server security configuration which by default includes either name/password or a private key file with a password for it. We can probably enhance that to include realm name, or can use server id for the realm, which is less flexible. The Binding - namely url there - does not have any links to server id, but I can get that mapping from a remote repository descriptor and feed to jetty client. The overall interaction seem to be: * mercury reads all remote repository descriptors and their credentials * mercury feeds all the repositories and credentials to jetty client when instantiating it * you add repository id to the Binding * mercury always fills in the repository id in all the bindings, so that jetty client knows which credentials to use * if binding's repository is null - assume that repository is not protected What do you think? Thanks, Oleg Jesse McConnell wrote: 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]
Re: artifact retrieval, mercury, and jetty-client
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]
Re: artifact retrieval, mercury, and jetty-client
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]
Re: artifact retrieval, mercury, and jetty-client
On 18/07/2008, at 10:11 AM, Jason van Zyl wrote: I'll sync up with Oleg and takes the notes out of SVN and put them in a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon Shane will have their fingers in the pie. This is a pretty significant effort and should be documented. It's mostly the processes and algorithms that need to be vetted. Yes, I think that's essential to getting others involved. The previous discussion about the SAT solver was a helpful starting point, and I like the direction it is taking, but more info needs to be spelled out. Here are my current questions I'd like to see addressed by it: - spell out the problems in the current artifact mechanism already solved by it (eg, conflict resolution, reduced metadata consultation, deterministic?) - what infrastructure/metadata changes it will require server side - how/if deployment will be handled or delegated wagon - how it's going to be integrated into Maven proper If I can see a path to adoption for it I'm more likely to get involved myself. On 17-Jul-08, at 7:26 PM, Jesse McConnell wrote: 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 :) Thanks for getting the ball rolling Jesse! Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact retrieval, mercury, and jetty-client
I'll sync up with Oleg and takes the notes out of SVN and put them in a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon Shane will have their fingers in the pie. This is a pretty significant effort and should be documented. It's mostly the processes and algorithms that need to be vetted. On 17-Jul-08, at 7: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. 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
