ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: PROPOSAL to merge Rampart, CXF, swssf AssertionBuilder and Assertion classes
Date Mon, 14 Nov 2011 13:03:50 GMT
> 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.

I agree with this. Why not just use the CXF model instead, given that
it meets the requirements?

Colm.


On Fri, Nov 11, 2011at 6:53 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
>> 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.
>
> Dan
>
>
>
>
> 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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message