> 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 <dk...@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 > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org > For additional commands, e-mail: dev-h...@ws.apache.org > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
