ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: PROPOSAL to merge Rampart, CXF, swssf AssertionBuilder and Assertion classes
Date Fri, 11 Nov 2011 18:53:15 GMT

> I agree [   x  ]

I definitely agree with the idea.   If you look back at the Neethi 3 
discussions, this was one of my primary motivations for the changes in Neethi 
3.    It allows creating policy models that are more re-usable.

My ONLY concern is that the CXF model has come a long way in the last couple 
years.  It supports a lot of other token types and custom algorithm things and 
such that the rampart model doesn't.   Thus, we'll definitely need to go 
through the CXF model and find the updates and fixes.   Either that, or start 
with the CXF model, not the Rampart one, since the CXF model should be 
completely Neethi3, DOM based, etc.... and pretty much meets all the same 
requirements you listed.


On Thursday, November 10, 2011 8:02:48 PM Marc Giger wrote:
> Dear WS-devs,
> At the moment there are at least 4 AssertionBuilder and 3 Assertion classes
> per WS-Security-Policy-Assertion. The original Rampart ones, the CXF ones
> lent by rampart and my classes (swssf) lent by Rampart. All of you, which
> did contribute to the policy implementations, know how much time it takes
> to implement it and how complicated it can be.
> The attached patch is a first try/draft/proposal to to get rid of this
> overhead so that we can use a common code base. It is of course not
> intended for inclusion but to start a discussion about requirements.
> The provided patch should show you
> - the support of neested policies and its normalization (attached is a
> sample policy in compact form and its normalized version which was
> normalized with the code in the patch) - the simplification of the multiple
> Policy-Versions handling
> - generic (simple) method and class to do the final assert of an alternative
> The axis/rampart developers will note that the builders are using the
> W3C-DOM implementation instead of the axiom framework. The rationale is
> that no additional dependencies are needed, DOM is an official standard and
> we aren't in a "hot-path" (Normally the policy will be build once during
> the whole runtime). So, this shouldn't be a big deal.
> There is an alternative to the proposed concept. Build the policy without
> the builders and call the concrete builders during normalization or during
> other structural changes. The primitive assertion objects can be hold
> behind the scene to allow structural changes all the time.
> Before I invest more time I want to make sure the asf-dev-community is in
> favor and the result will be accepted.
> What do you think?
> I agree [ ]
> I disagree [ ]
> I don't care [ ]
> What do you want?, it is perfect as it is! [ ]
> I'm willing to help [ ]
> Comments/notes/concerns/objections/ideas?
> Please share your opinion!
> Thanks
> Marc
Daniel Kulp
Talend -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message