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]
