Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of andreas.veithen@gmail.com
 designates 209.85.216.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=Ua/4rFxW9x/FmZSeCsAocMoPdhKJKt+CZAKVFa7zb0VSEEMLxhw0M73SnTPYWTefTm
         kknE8LEUwnd4r3eJyi8g2OGxobE7VzbuDbqk/kuMoPz/+L5wKLGQWJ/I9rAtNENwkAJk
         jM7trYb+kzpCsKbgdvx9fVtFCalVsB7DMLSp8=
MIME-Version: 1.0
In-Reply-To: <201010111403.45858.dkulp@apache.org>
References: 
 <BCCA9B57FEE894408005513A58B8CF1D05A9128ADA@EXMBX01.SFP-Net.skyfillers.local>
 <201010081213.23000.dkulp@apache.org>
 <AANLkTikaOkQVite47drdP9+opgWhOKF0mywrLxVsqTWc@mail.gmail.com>
 <201010111403.45858.dkulp@apache.org>
From: Andreas Veithen <andreas.veithen@gmail.com>
Date: Sat, 16 Oct 2010 16:56:45 +0200
Message-ID: <AANLkTi=AZkYDAcrqsMjytnjPBU_c2VEm4=kESOi_pTDT@mail.gmail.com>
Subject: Re: Security token processing without SAAJ dependency
To: Daniel Kulp <dkulp@apache.org>
Cc: dev@cxf.apache.org, Colm O hEigeartaigh <coheig@gmail.com>,
	Dennis Sosnoski <dms@sosnoski.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2010 at 20:03, Daniel Kulp <dkulp@apache.org> wrote:
> On Saturday 09 October 2010 9:13:27 am Andreas Veithen wrote:
>> On Fri, Oct 8, 2010 at 18:13, Daniel Kulp <dkulp@apache.org> wrote:
>> > And I think this is where the issues may start popping up, but definit=
ely
>> > resolvable. =A0If you look at the CXF survey, one of the MAJOR "areas =
of
>> > improvement" for CXF was too many external dependencies. =A0 I'm kind =
of
>> > reluctant to add more "required" deps. =A0 Thus, the security stuff wo=
uld
>> > need to work with the default SAAJ impl (in particular, the one built
>> > into the JDK), but I could definitely see making something like this a=
s
>> > an optional "performance enhancment" type thing. =A0Ideally, the exist=
ing
>> > SAAJ interceptor would be smart enough to checkt he SAAJ impl being us=
ed
>> > and do the smart thing depending on what it sees.
>>
>> What about the following solution:
>> * Introduce a new SAAJManager interface that encapsulates the SAAJ
>> handling stuff.
>> * Create a default implementation based on the code currently
>> contained in the standard SAAJ interceptors.
>> * Refactor SAAJInInterceptor and SAAJOutInterceptor to look up the
>> SAAJManager using Bus#getExtension. If none is found, fall back to the
>> default implementation.
>> * Maybe also refactor the WSS4J interceptors to use SAAJManager
>> instead of instantiating SAAJ(In|Out)Interceptor.
>> * My ddom-cxf stuff would then provide an alternative SAAJManager
>> implementation and automatically register that as a bus extension.
>
> Sure. =A0 That works. =A0:-)

Now we only need somebody who does the SAAJ and WSS4J interceptor
refactoring to create the extension point. How are we going to do
this?

>> > If the DDOM stuff we need can be squashed/shaded
>> > into a single jar that is just a drop in replacement of saaj-impl, tha=
t
>> > concern could also be aleviated quite a bit as well.
>>
>> Yes, I was also thinking the same. There are a couple of other reasons
>> why this is a good idea:
>> * The DDOM project is split into a multitude of smaller modules, so
>> that for every use case, you only get the stuff that is really needed
>> (e.g. some modules depend on the Axiom APIs, but you don't want that
>> as a transitive dependency for the CXF stuff ;-). This works well when
>> Maven is used, but of course it's a pain for users who use other
>> tools.
>> * The code in the CXF stuff is (currently) tightly coupled to some
>> internal DDOM APIs that are likely to change over time. Thus,
>> packaging all the required stuff into a single JAR and shade it makes
>> sense because it avoids conflicts caused by incompatible versions of
>> DDOM modules.
>
> That all makes sense. =A0 Keeping the dep list small is definitely a welc=
ome
> thing.
>
>
>> > That said, the callback method added to WSS4J has an additional use ca=
se
>> > that Sergey and I have been noodling on outside of SOAP. =A0 =A0One th=
ing
>> > we're trying to figure out how to do is leverage some of the WS-SecPol
>> > support to provide message level security for XML REST payloads. =A0Wi=
th
>> > the callback, we MAY be able to have separate XML sources for the
>> > security header and the actual payload (think separate MIME containers=
)
>> > where we feed the security header into WSS4J, and it calls back out to
>> > us to load the other parts as/if needed. Very early in the "noodling i=
n
>> > our heads" stages. =A0 =A0:-)
>>
>> The DDOM solution here would simply be to compose the equivalent SOAP
>> message and pass that to WSS4J. This would mean creating a skeleton
>> SOAP message and adding the source objects for the header and body
>> parts to that skeleton. It is definitely possible to defer the
>> expansion of these parts (and even the lookup of the corresponding
>> MIME parts from the message) until the very last moment. This is
>> conceptually similar to your solution except that the callbacks are
>> invoked by the DOM/SAAJ implementation instead of WSS4J. This could
>> have some advantages:
>>
>> * The scope of WSS4J would remain strictly limited to WS-Security and
>> no API changes are needed.
>> * If I understand your idea correctly, then conceptually you are
>> defining a mapping between REST style requests/responses and SOAP
>> messages conforming to WS-Security. With DDOM, the code that
>> implements this would simply be a direct transcription of these
>> mapping rules (plus of course some glue code).
>
> This is beginning to sound too much like Synapse.
>
> Seriously, this isn't ideal for certain policy elements. =A0 For example,=
 an
> XPATH expression for the encrypted elements should, ideally, not have any=
 soap
> things in it for a REST invokation. =A0 =A0 I'd need to think about this =
some more
> though. =A0The main issue here would be the fact that the Message object =
that is
> passed from Interceptor to Interceptor when using JAX-RS is not a SoapMes=
sage.
> It's probably just a MessageImpl. =A0 =A0If you try to even configure any=
 of the
> WSS4J or SAAJ interceptors onto the JAX-RS chains, it will throw and exce=
ption
> before the handleMessage call is even called. =A0 The Java runtime won't =
even
> allow it. =A0The WSS4J interceptors would need to be updated to adjust fo=
r that
> anyway.

You are correct here. If one specifies REST security by defining
equivalencies between REST request/responses and SOAP messages, then
there is indeed a problem for XPath expressions.

>> >> It also
>> >> successfully passes the most important parts of the DOM3 test suite.
>> >> * When configured as SAAJ implementation in the CXF build (without th=
e
>> >> custom SAAJInInterceptor), it passes all unit tests up to the systest=
s
>> >> (It seems that this is primarily due to the fact that some of the
>> >> systests use SAAJ to compose test messages).
>> >
>> > Likely yes. =A0 Do you have a feeling as to whether =A0those are issue=
s in
>> > the CXF tests or issues with DDOM?
>>
>> These are issues in DDOM. They are simply due to the fact that many
>> SAAJ methods in DDOM are still unimplemented ;-).
>
> It's almost a shame you are doing this at google instead of in Apache
> someplace. =A0 Apache has access to the standalone SAAJ TCK for testing t=
hat,
> but we're only really allowed to test it on Apache projects. =A0Maybe con=
vince
> Geronimo to try using DDOM as an optional SAAJ impl and see how the SAAJ =
J2EE
> tests progress. =A0 Oh well.

Yes and no. The scope, goals and architecture of the project have
changed quite a lot over time. It grew out of some code that was
initially built on top of Axiom and then recycled into a pure DOM
implementation supporting deferred parsing and building (hence the
name DDOM). Only later I noticed that by using bytecode manipulation
(first with AspectJ and now using a custom ASM based weaver) it is
possible to support multiple APIs (DOM, SAAJ, Axiom) and even to mix
them (DOM+Axiom). At this point, the primary goal became to provide a
decent replacement for Axiom DOOM in order to solve some of the
performance problems with WS-Security processing in Axis2. Even now,
the scope of the project is still changing. E.g. the idea to use it as
a SAAJ implementation that enables tighter integration into an
existing SOAP stack is new and actually grew out of this discussion.

I think that doing the first phases of the project outside of Apache
was necessary to have the required freedom and flexibility for this
kind of changes in scope and goals and to explore new use cases and
solutions. The question is not so much whether this should become or
not an Apache project, but where, how and when this should happen.

>> What I wanted to say
>> here is that there is enough stuff in DDOM's SAAJ implementation to
>> play nicely with CXF's own code. Of course, once the SOAPMessage is
>> exposed to user code through a JAX-WS handler or provider endpoint,
>> this is no longer enough. As I said, for the moment it's a PoC.
>
> OK. =A0Makes sense. =A0 Gotta start someplace. =A0 :-)
>
>
>> > I see in the code that it doesn't support attachments either. =A0 That
>> > would be required for the JAX-WS TCK. =A0(and likely for some of the
>> > systests as well) That said, those should be fairly easy to handle sin=
ce
>> > you have the SoapMessage. =A0 =A0 The DDOM version could be MUCH more
>> > efficient by not buffering the attachments unless they really are
>> > accessed. =A0 =A0One of my "issues" with the JAX-WS handlers is they r=
equire
>> > us to stop streaming EVERYTHING and buffer it, even if the only thing
>> > the =A0handler does is: System.out.println("Hello World!");
>> > this could be a huge help with that.
>>
>> The SAAJ stuff in DDOM is actually split into two parts:
>> * The part that implements the SAAJ object model. This contains the
>> code that extends DOM and also some partial implementations of
>> SOAPMessage and SOAPPart. On the other hand, it doesn't contain any
>> MIME parsing or attachment management logic.
>
> And it shouldn't need to contain any MIME parsing stuff for the CXF versi=
on.
> CXF has already taken care of that.
>
>> * The part that provides the SAAJ factories and thus the complete SAAJ
>> implementation. Of course this part depends on the first part and will
>> eventually contain the MIME parsing logic to satisfy the requirements
>> of the SAAJ spec.
>
> But we don't use any of that in CXF. =A0 So irrelevant for a first pass C=
XF
> integration. =A0 Once we get into using it to support Dispatch clients an=
d
> Provider based services, I suppose it would be required though.

I think you got the idea ;-)

>
>> When running the CXF test suites against DDOM I use both parts as a
>> drop-in replacement for Sun's saaj-impl. On the other hand, the custom
>> SAAJInInterceptor only uses the first part. This means that the
>> SOAPMessage implementation is not the same as the one that would be
>> created by MessageFactory. Instead it uses an implementation that is
>> basically a wrapper around a org.apache.cxf.binding.soap.SoapMessage
>> object. This can be seen here:
>>
>> http://ddom.googlecode.com/svn/trunk/modules/ddom-cxf/src/main/java/com/=
goo
>> glecode/ddom/cxf/SOAPMessageImpl.java
>
> Right. =A0 I was looking at that.
>
>
>> The idea is that the methods that are used to manage attachments (and
>> that are currently unimplemented) would all delegate to the
>> corresponding CXF APIs. This means that all optimizations done by CXF
>> would also work when accessing the attachments through SAAJ. Since
>> SAAJ exposes attachments via iterators, the only case were all
>> attachments are buffered would be a call to countAttachments...
>
> OK. =A0 I didn't read far enough again. =A0:-) =A0 It's pretty easy. =A0T=
he CXF
> SoapMessage (or just Message) has an Attachment list that can be retrieve=
d
> via:
>
> Collection<Attachment> attachments =3D
> CastUtils.cast((Collection<?>)mc.get(Message.ATTACHMENTS));
>
> That can easily be wrapped or similar to implement the required SAAJ API'=
s.
>
>
>
> Anyway, this is definitely all very interesting. =A0 Thanks for pursuing =
this.
> Kind of can't wait till Colm frees up a bit to have his brain noodling on
> things as well. =A0 :-)
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>