Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of olivier.ottavi@gmail.com
 designates 209.85.128.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=IzfjcRegMN9nDf58HC84UFBUD0hS1DlIgNxx0oD8KXLNaAecOKjnmotV/IgHP1A0i8zyBOqZhArrx3TBSF8FqFrquQgdsPOezBXOPMo7C7h8cAl/TogDsWrDwfzFBJcIPpOvdUHssc1OoOa2dhAttgv0/SdRZH2ooOP3G9SRXZo=
Message-ID: <4ec0c7d80712151637v1a5bde61n9d5b6933118a7b58@mail.gmail.com>
Date: Sun, 16 Dec 2007 01:37:18 +0100
From: "Olivier OTTAVI" <olivier.ottavi@gmail.com>
To: cxf-dev@incubator.apache.org
Subject: Re: WS-Signature with server encryption
In-Reply-To: <DC697AC0-1437-4844-B5F8-98F72B3AA1B7@dushin.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4289_15549584.1197765438452"
References: <4ec0c7d80712150857r760fae1bv19fc09c91937b612@mail.gmail.com>
	 <DC697AC0-1437-4844-B5F8-98F72B3AA1B7@dushin.net>

------=_Part_4289_15549584.1197765438452
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is pretty bad, because it is a common scenario in mutual authentication
- the fact is also that this feature is integreted by the WSS4J library but
only for the Axis version (WSDoAllReceiver.java) and is handled properely
with the handleSpecialUser of the WSHandler class , nothing has been done
inside of CXF to do integration with this feature. There is a lack of
support and integration here between CXF and WSS4J, on the specific feature
useReqSigCert which is in my opinion very sensitive. This should again in my
opinion clearly appear on the wiki, to avoid misschoice between open source
webservice stacks for potential users.

On 12/15/07, Fred Dushin <fred@dushin.net> wrote:
>
> To my knowledge, there isn't, no, and this is a very compelling use
> case.
>
> I'd suggest doing this programatically through a collection of
> interceptors, one which places the client's public key on the
> Exchange after the inbound interceptor has consumed the message, and
> another that programatically configures the OutInterceptor on the
> outbound response interceptor chain, using the key you've placed on
> the exchange.
>
> The wrinkle in all of this is that CXF uses WSS4J, which IMO is
> pretty limited in its ability to configure keys.  Worse, CXF uses the
> WSS4J Handler architecture, which makes invalid assumptions about
> keys are retrieved.
>
> So I guess I'm saying I don't know how feasible my proposal is, but
> it's the avenue of investigation I'd start with, if I were to do what
> you are trying to do.  (And I've considered it as a possibility)
>
> Hope that helps more than it discourages you!
> -Fred
>
> On Dec 15, 2007, at 11:57 AM, Olivier OTTAVI wrote:
>
> > Hi,
> >
> >  I have a server with WS-Security enabled on WSS4J, in order to handle
> > signature and encryption of the soap message.
> >
> >  The client encrypt the soap message with server public key, and
> > sign it
> > with its private key. The server validate signature with public
> > client key
> > and decrypt it with its private key.
> >
> >  Then the response is sent to the client - signed by the private
> > server key
> > and encrypted with the client public key.
> >
> >  It works well, but the only thing that bother me, is that the server
> > encryption has to be done by setting up the "encryption user"
> > property with
> > the client name. Since this name is changing for each request, I
> > don't know
> > where to put this information. I would like to have the public key
> > of the
> > client that signed the request directly used to encrypt the
> > response, is
> > there a simple way to achieve this behavior ?
> >
> > Thanks
>
>

------=_Part_4289_15549584.1197765438452--