You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Davanum Srinivas <da...@gmail.com> on 2005/09/14 06:20:46 UTC
Refactoring (Re: WSS4J future)
Hans, Werner,
I've refactored a bunch of stuff and added a package called processors
(for processing dom elements that are encountered by the security
engine) and actions (things that the user has asked the handler to
do). Could you guys please take a look? and comment? if it shows
promise i'll do more work when i get a change. Basically it breaks up
all the stuff into pieces that are loaded when needed (trying to get a
handle on #1 below)
#2, wsdd's how services are configured in Axis. If we can write a
WS-SecurityPolicy Processor, we could replace the complicated
parameter stuff with a link to a single xml in the wsdd.
#3, Folks pick up what they need and put them together. Kirill is
demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM (Axis1.X, WSS4J,
Sandesha, Addressing) more on that later :)
thanks,
dims
On 9/13/05, Granqvist, Hans <hg...@verisign.com> wrote:
> > > I would really like to have a discussion/exchange of ideas how to
> > > improve the code, add a "plugin" feature for various functions like
> > > SAML, Kerberos, etc (Dims asked about that a time ago).
>
> First of all: I don't want to step on anyone's toes. Don't get
> discouraged. Just some ideas and thoughts below.
>
> 1) I'd like to see if I can re-architect a few areas of WSS4J and
> make some portions less coupled. Some of the handlers seem
> monolithic and too hard to understand. The code is somewhat too
> relaxed in syntax, javadoc, etc., and makes a sloppy impression
> (which is bad since the code doesn't seem that bad once you look
> closer, but it probably scares off potential developers they way
> it looks now.)
>
> 2) There is something about the wsdd files that bothers me, but I
> can't figure out if it's a vestige of Axis. Anyone feel the same?
> Quite a few questions to the list relate to these deployment files.
> All the "XML situps" seem error prone and a security risk, too.
> These files could be pre-packaged and signed, and somehow mapped
> to policies, perhaps.
>
> 3) I lack a "user's vision" how all the ws.apache.org projects work
> together. For example, if I want to use, say, WS-Trust, would I (as
> a WSS4J user) collate the various ws.apache.org project JARs that
> WS-Trust depend on, or would there be separate deployment steps to
> get, say, the WS-Addressing parts needed? There seems too much
> fragmentation. But perhaps I exaggerate?
>
> Okay, my chin is out. Feel free to pound on it :)
>
> Hans
>
>
>
> > -----Original Message-----
> > From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> > Sent: Monday, September 12, 2005 11:48 PM
> > To: Granqvist, Hans
> > Cc: wss4j-dev@ws.apache.org
> > Subject: Re: WSS4J future
> >
> > Hans,
> >
> > just forgot:
> > the WSS4J core library does not depend on Axis. It is
> > possible to use other SOAP stacks / SOAP engines as well.
> > AFAIK there are other implementations for other SOAP engines.
> >
> > Only the handlers depend on the underlying SOAP engines.
> > Currently we provide handlers for Axis and JAX-RPC SOAP
> > engines. The handlers use the WSS4J library / methods.
> >
> > This decoupling of core and handler was one of the first
> > steps during WSS4J development.
> >
> > Regards,
> > Werner
> >
> > Werner Dittmann wrote:
> > > Hans,
> > >
> > > ther are is real roadmap / versions planning. We try to
> > keep up with
> > > the specs, interop problems with .Net etc. The whole developer team
> > > for the core are just 2-3 people, all really part time. Thus it was
> > > just not possible to do more as to keep up with specs and interop
> > > problems.
> > >
> > > For sure there are some areas that need code improvements, in
> > > partiular the whole error/exception handling needs to be
> > cleaned up.
> > > Also to make it more compliant the the specs in terms of
> > error code, messages etc.
> > >
> > > Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their
> > > project, maybe Dims as "the master" :-) can give you more info.
> > >
> > > Sandbox: Dims did it and put code in it that is not yet part of the
> > > official WSS4J release (Trust, Secure Conversation). See the README.
> > >
> > > As for DOM centic: yes, you are right. IMHO it is not easy
> > to use SAX
> > > or pull parsers or other optimizations. Several reasons:
> > > - during Security processing you often must alter existing elements,
> > > e.g. in the Body, replace elements, insert new elements
> > > - The scurity elements need to refer to elements in the Body and
> > > elsewhere.
> > > - if you need to sign/encrypt you need the real content and, in case
> > > of encryption, replace it with the encrypted data.
> > > - depeding on the order of the security actions to perform you may
> > > again need to reference / sign these elements
> > > - last but not least: the libraries WSS4J uses (xml-sec, xalan) are
> > > also based on DOM.
> > >
> > > Many of these things need a "full tree" to be able to
> > navigate inside
> > > the tree and modify it where needed.
> > >
> > > While it may be possible to rewrite WSS4J to use SAX or
> > pull parsers
> > > it will introduce additional logic to keep track of references,
> > > element replacements etc. These functions are available in
> > DOM. Thus,
> > > IMHO, it would not be simpler - maybe even more complex
> > from the WSS4J
> > > code point of view.
> > >
> > > Thoughts?
> > >
> > > Regards,
> > > Werner
> > >
> > > Granqvist, Hans wrote:
> > >
> > >>Hi developers,
> > >>
> > >>I currently work on the a ws.apache.org incubation project
> > [1], and I
> > >>want to see how I can contribute to wss4j and ws.apache.org.
> > >>
> > >>I've spent some time going through the wss4j source, but I lack an
> > >>overall view of what you all currently work on, or what you plan to
> > >>work on, now and in the close future. Is there a roadmap?
> > Is there
> > >>also a list of who's involved with which standards bodies
> > development?
> > >>
> > >>Are there areas in the wss4j code that you feel could be improved?
> > >>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but
> > >>I'd like to know what you think the real itches are (there must be
> > >>some? ;)
> > >>
> > >>Are there any ideas in the core/plugin/addon structure of
> > [1] that you
> > >>think makes sense to use/work on in wss4j? (Please note that the
> > >>javadocs link in [1] is somewhat out-of-date currently.)
> > >>
> > >>What does Axis2 mean for the wss4j development? Are there Axis v1
> > >>areas of wss4j that I should not waste time on because of something
> > >>else, something better in the works? I'd hate to start working on
> > >>something that is slated to go away.
> > >>
> > >>Part of my personal drive is to try to implement the
> > identity system
> > >>(see more info in [2]) and that would involve some work implementing
> > >>WS-* standards, plus potentially some interesting end-user APIs.
> > >>Previous emails [3] on for example WS-Trust sound promising, but
> > >>directions are somewhat unclear. Comments, ideas, prioritizations,
> > >>etc., mucho welcome.
> > >>
> > >>The various ws.apache.org projects working together in a non-Axis
> > >>setting -- is that concept out-of-scope?
> > >>
> > >>wss4j is currently quite DOM-centric. Do we want to get away from
> > >>that? SAX, push-pull, etc.?
> > >>
> > >>
> > >>Thanks for your time,
> > >>Hans
> > >>
> > >>PS. I have to end with a perhaps naïve question: What
> > exactly is meant
> > >>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't
> > >>figure it out.
> > >>
> > >>[1] http://incubator.apache.org/tsik
> > >>[2] http://incubator.apache.org/tsik/roadmap.html
> > >>[3]
> > >>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508
> > .mbox/%3C5
> > >>59c463d050831142314dacd7e@mail.gmail.com%3E
> > >>
> > >>------------------------------------------------------------
> > ---------
> > >>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > >>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >>
> > >>
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Refactoring (Re: WSS4J future)
Posted by Werner Dittmann <We...@t-online.de>.
Dims,
great job, well done :-).
I'll dig into this later this day to see if anything works as
expected.
Regards,
Werner
Davanum Srinivas wrote:
> Hans, Werner,
>
> I've refactored a bunch of stuff and added a package called processors
> (for processing dom elements that are encountered by the security
> engine) and actions (things that the user has asked the handler to
> do). Could you guys please take a look? and comment? if it shows
> promise i'll do more work when i get a change. Basically it breaks up
> all the stuff into pieces that are loaded when needed (trying to get a
> handle on #1 below)
>
> #2, wsdd's how services are configured in Axis. If we can write a
> WS-SecurityPolicy Processor, we could replace the complicated
> parameter stuff with a link to a single xml in the wsdd.
>
> #3, Folks pick up what they need and put them together. Kirill is
> demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM (Axis1.X, WSS4J,
> Sandesha, Addressing) more on that later :)
>
> thanks,
> dims
>
>
> On 9/13/05, Granqvist, Hans <hg...@verisign.com> wrote:
>
>>>>I would really like to have a discussion/exchange of ideas how to
>>>>improve the code, add a "plugin" feature for various functions like
>>>>SAML, Kerberos, etc (Dims asked about that a time ago).
>>
>>First of all: I don't want to step on anyone's toes. Don't get
>>discouraged. Just some ideas and thoughts below.
>>
>>1) I'd like to see if I can re-architect a few areas of WSS4J and
>>make some portions less coupled. Some of the handlers seem
>>monolithic and too hard to understand. The code is somewhat too
>>relaxed in syntax, javadoc, etc., and makes a sloppy impression
>>(which is bad since the code doesn't seem that bad once you look
>>closer, but it probably scares off potential developers they way
>>it looks now.)
>>
>>2) There is something about the wsdd files that bothers me, but I
>>can't figure out if it's a vestige of Axis. Anyone feel the same?
>>Quite a few questions to the list relate to these deployment files.
>>All the "XML situps" seem error prone and a security risk, too.
>>These files could be pre-packaged and signed, and somehow mapped
>>to policies, perhaps.
>>
>>3) I lack a "user's vision" how all the ws.apache.org projects work
>>together. For example, if I want to use, say, WS-Trust, would I (as
>>a WSS4J user) collate the various ws.apache.org project JARs that
>>WS-Trust depend on, or would there be separate deployment steps to
>>get, say, the WS-Addressing parts needed? There seems too much
>>fragmentation. But perhaps I exaggerate?
>>
>>Okay, my chin is out. Feel free to pound on it :)
>>
>>Hans
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>>Sent: Monday, September 12, 2005 11:48 PM
>>>To: Granqvist, Hans
>>>Cc: wss4j-dev@ws.apache.org
>>>Subject: Re: WSS4J future
>>>
>>>Hans,
>>>
>>>just forgot:
>>>the WSS4J core library does not depend on Axis. It is
>>>possible to use other SOAP stacks / SOAP engines as well.
>>>AFAIK there are other implementations for other SOAP engines.
>>>
>>>Only the handlers depend on the underlying SOAP engines.
>>>Currently we provide handlers for Axis and JAX-RPC SOAP
>>>engines. The handlers use the WSS4J library / methods.
>>>
>>>This decoupling of core and handler was one of the first
>>>steps during WSS4J development.
>>>
>>>Regards,
>>>Werner
>>>
>>>Werner Dittmann wrote:
>>>
>>>>Hans,
>>>>
>>>>ther are is real roadmap / versions planning. We try to
>>>
>>>keep up with
>>>
>>>>the specs, interop problems with .Net etc. The whole developer team
>>>>for the core are just 2-3 people, all really part time. Thus it was
>>>>just not possible to do more as to keep up with specs and interop
>>>>problems.
>>>>
>>>>For sure there are some areas that need code improvements, in
>>>>partiular the whole error/exception handling needs to be
>>>
>>>cleaned up.
>>>
>>>>Also to make it more compliant the the specs in terms of
>>>
>>>error code, messages etc.
>>>
>>>>Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their
>>>>project, maybe Dims as "the master" :-) can give you more info.
>>>>
>>>>Sandbox: Dims did it and put code in it that is not yet part of the
>>>>official WSS4J release (Trust, Secure Conversation). See the README.
>>>>
>>>>As for DOM centic: yes, you are right. IMHO it is not easy
>>>
>>>to use SAX
>>>
>>>>or pull parsers or other optimizations. Several reasons:
>>>>- during Security processing you often must alter existing elements,
>>>> e.g. in the Body, replace elements, insert new elements
>>>>- The scurity elements need to refer to elements in the Body and
>>>> elsewhere.
>>>>- if you need to sign/encrypt you need the real content and, in case
>>>> of encryption, replace it with the encrypted data.
>>>>- depeding on the order of the security actions to perform you may
>>>> again need to reference / sign these elements
>>>>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>>>> also based on DOM.
>>>>
>>>>Many of these things need a "full tree" to be able to
>>>
>>>navigate inside
>>>
>>>>the tree and modify it where needed.
>>>>
>>>>While it may be possible to rewrite WSS4J to use SAX or
>>>
>>>pull parsers
>>>
>>>>it will introduce additional logic to keep track of references,
>>>>element replacements etc. These functions are available in
>>>
>>>DOM. Thus,
>>>
>>>>IMHO, it would not be simpler - maybe even more complex
>>>
>>>from the WSS4J
>>>
>>>>code point of view.
>>>>
>>>>Thoughts?
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>Granqvist, Hans wrote:
>>>>
>>>>
>>>>>Hi developers,
>>>>>
>>>>>I currently work on the a ws.apache.org incubation project
>>>
>>>[1], and I
>>>
>>>>>want to see how I can contribute to wss4j and ws.apache.org.
>>>>>
>>>>>I've spent some time going through the wss4j source, but I lack an
>>>>>overall view of what you all currently work on, or what you plan to
>>>>>work on, now and in the close future. Is there a roadmap?
>>>
>>>Is there
>>>
>>>>>also a list of who's involved with which standards bodies
>>>
>>>development?
>>>
>>>>>Are there areas in the wss4j code that you feel could be improved?
>>>>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but
>>>>>I'd like to know what you think the real itches are (there must be
>>>>>some? ;)
>>>>>
>>>>>Are there any ideas in the core/plugin/addon structure of
>>>
>>>[1] that you
>>>
>>>>>think makes sense to use/work on in wss4j? (Please note that the
>>>>>javadocs link in [1] is somewhat out-of-date currently.)
>>>>>
>>>>>What does Axis2 mean for the wss4j development? Are there Axis v1
>>>>>areas of wss4j that I should not waste time on because of something
>>>>>else, something better in the works? I'd hate to start working on
>>>>>something that is slated to go away.
>>>>>
>>>>>Part of my personal drive is to try to implement the
>>>
>>>identity system
>>>
>>>>>(see more info in [2]) and that would involve some work implementing
>>>>>WS-* standards, plus potentially some interesting end-user APIs.
>>>>>Previous emails [3] on for example WS-Trust sound promising, but
>>>>>directions are somewhat unclear. Comments, ideas, prioritizations,
>>>>>etc., mucho welcome.
>>>>>
>>>>>The various ws.apache.org projects working together in a non-Axis
>>>>>setting -- is that concept out-of-scope?
>>>>>
>>>>>wss4j is currently quite DOM-centric. Do we want to get away from
>>>>>that? SAX, push-pull, etc.?
>>>>>
>>>>>
>>>>>Thanks for your time,
>>>>>Hans
>>>>>
>>>>>PS. I have to end with a perhaps naïve question: What
>>>
>>>exactly is meant
>>>
>>>>>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't
>>>>>figure it out.
>>>>>
>>>>>[1] http://incubator.apache.org/tsik
>>>>>[2] http://incubator.apache.org/tsik/roadmap.html
>>>>>[3]
>>>>>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508
>>>
>>>.mbox/%3C5
>>>
>>>>>59c463d050831142314dacd7e@mail.gmail.com%3E
>>>>>
>>>>>------------------------------------------------------------
>>>
>>>---------
>>>
>>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Refactoring (Re: WSS4J future)
Posted by Werner Dittmann <We...@t-online.de>.
Dims,
great job, well done :-).
I'll dig into this later this day to see if anything works as
expected.
Regards,
Werner
Davanum Srinivas wrote:
> Hans, Werner,
>
> I've refactored a bunch of stuff and added a package called processors
> (for processing dom elements that are encountered by the security
> engine) and actions (things that the user has asked the handler to
> do). Could you guys please take a look? and comment? if it shows
> promise i'll do more work when i get a change. Basically it breaks up
> all the stuff into pieces that are loaded when needed (trying to get a
> handle on #1 below)
>
> #2, wsdd's how services are configured in Axis. If we can write a
> WS-SecurityPolicy Processor, we could replace the complicated
> parameter stuff with a link to a single xml in the wsdd.
>
> #3, Folks pick up what they need and put them together. Kirill is
> demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM (Axis1.X, WSS4J,
> Sandesha, Addressing) more on that later :)
>
> thanks,
> dims
>
>
> On 9/13/05, Granqvist, Hans <hg...@verisign.com> wrote:
>
>>>>I would really like to have a discussion/exchange of ideas how to
>>>>improve the code, add a "plugin" feature for various functions like
>>>>SAML, Kerberos, etc (Dims asked about that a time ago).
>>
>>First of all: I don't want to step on anyone's toes. Don't get
>>discouraged. Just some ideas and thoughts below.
>>
>>1) I'd like to see if I can re-architect a few areas of WSS4J and
>>make some portions less coupled. Some of the handlers seem
>>monolithic and too hard to understand. The code is somewhat too
>>relaxed in syntax, javadoc, etc., and makes a sloppy impression
>>(which is bad since the code doesn't seem that bad once you look
>>closer, but it probably scares off potential developers they way
>>it looks now.)
>>
>>2) There is something about the wsdd files that bothers me, but I
>>can't figure out if it's a vestige of Axis. Anyone feel the same?
>>Quite a few questions to the list relate to these deployment files.
>>All the "XML situps" seem error prone and a security risk, too.
>>These files could be pre-packaged and signed, and somehow mapped
>>to policies, perhaps.
>>
>>3) I lack a "user's vision" how all the ws.apache.org projects work
>>together. For example, if I want to use, say, WS-Trust, would I (as
>>a WSS4J user) collate the various ws.apache.org project JARs that
>>WS-Trust depend on, or would there be separate deployment steps to
>>get, say, the WS-Addressing parts needed? There seems too much
>>fragmentation. But perhaps I exaggerate?
>>
>>Okay, my chin is out. Feel free to pound on it :)
>>
>>Hans
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>>Sent: Monday, September 12, 2005 11:48 PM
>>>To: Granqvist, Hans
>>>Cc: wss4j-dev@ws.apache.org
>>>Subject: Re: WSS4J future
>>>
>>>Hans,
>>>
>>>just forgot:
>>>the WSS4J core library does not depend on Axis. It is
>>>possible to use other SOAP stacks / SOAP engines as well.
>>>AFAIK there are other implementations for other SOAP engines.
>>>
>>>Only the handlers depend on the underlying SOAP engines.
>>>Currently we provide handlers for Axis and JAX-RPC SOAP
>>>engines. The handlers use the WSS4J library / methods.
>>>
>>>This decoupling of core and handler was one of the first
>>>steps during WSS4J development.
>>>
>>>Regards,
>>>Werner
>>>
>>>Werner Dittmann wrote:
>>>
>>>>Hans,
>>>>
>>>>ther are is real roadmap / versions planning. We try to
>>>
>>>keep up with
>>>
>>>>the specs, interop problems with .Net etc. The whole developer team
>>>>for the core are just 2-3 people, all really part time. Thus it was
>>>>just not possible to do more as to keep up with specs and interop
>>>>problems.
>>>>
>>>>For sure there are some areas that need code improvements, in
>>>>partiular the whole error/exception handling needs to be
>>>
>>>cleaned up.
>>>
>>>>Also to make it more compliant the the specs in terms of
>>>
>>>error code, messages etc.
>>>
>>>>Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their
>>>>project, maybe Dims as "the master" :-) can give you more info.
>>>>
>>>>Sandbox: Dims did it and put code in it that is not yet part of the
>>>>official WSS4J release (Trust, Secure Conversation). See the README.
>>>>
>>>>As for DOM centic: yes, you are right. IMHO it is not easy
>>>
>>>to use SAX
>>>
>>>>or pull parsers or other optimizations. Several reasons:
>>>>- during Security processing you often must alter existing elements,
>>>> e.g. in the Body, replace elements, insert new elements
>>>>- The scurity elements need to refer to elements in the Body and
>>>> elsewhere.
>>>>- if you need to sign/encrypt you need the real content and, in case
>>>> of encryption, replace it with the encrypted data.
>>>>- depeding on the order of the security actions to perform you may
>>>> again need to reference / sign these elements
>>>>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>>>> also based on DOM.
>>>>
>>>>Many of these things need a "full tree" to be able to
>>>
>>>navigate inside
>>>
>>>>the tree and modify it where needed.
>>>>
>>>>While it may be possible to rewrite WSS4J to use SAX or
>>>
>>>pull parsers
>>>
>>>>it will introduce additional logic to keep track of references,
>>>>element replacements etc. These functions are available in
>>>
>>>DOM. Thus,
>>>
>>>>IMHO, it would not be simpler - maybe even more complex
>>>
>>>from the WSS4J
>>>
>>>>code point of view.
>>>>
>>>>Thoughts?
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>Granqvist, Hans wrote:
>>>>
>>>>
>>>>>Hi developers,
>>>>>
>>>>>I currently work on the a ws.apache.org incubation project
>>>
>>>[1], and I
>>>
>>>>>want to see how I can contribute to wss4j and ws.apache.org.
>>>>>
>>>>>I've spent some time going through the wss4j source, but I lack an
>>>>>overall view of what you all currently work on, or what you plan to
>>>>>work on, now and in the close future. Is there a roadmap?
>>>
>>>Is there
>>>
>>>>>also a list of who's involved with which standards bodies
>>>
>>>development?
>>>
>>>>>Are there areas in the wss4j code that you feel could be improved?
>>>>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but
>>>>>I'd like to know what you think the real itches are (there must be
>>>>>some? ;)
>>>>>
>>>>>Are there any ideas in the core/plugin/addon structure of
>>>
>>>[1] that you
>>>
>>>>>think makes sense to use/work on in wss4j? (Please note that the
>>>>>javadocs link in [1] is somewhat out-of-date currently.)
>>>>>
>>>>>What does Axis2 mean for the wss4j development? Are there Axis v1
>>>>>areas of wss4j that I should not waste time on because of something
>>>>>else, something better in the works? I'd hate to start working on
>>>>>something that is slated to go away.
>>>>>
>>>>>Part of my personal drive is to try to implement the
>>>
>>>identity system
>>>
>>>>>(see more info in [2]) and that would involve some work implementing
>>>>>WS-* standards, plus potentially some interesting end-user APIs.
>>>>>Previous emails [3] on for example WS-Trust sound promising, but
>>>>>directions are somewhat unclear. Comments, ideas, prioritizations,
>>>>>etc., mucho welcome.
>>>>>
>>>>>The various ws.apache.org projects working together in a non-Axis
>>>>>setting -- is that concept out-of-scope?
>>>>>
>>>>>wss4j is currently quite DOM-centric. Do we want to get away from
>>>>>that? SAX, push-pull, etc.?
>>>>>
>>>>>
>>>>>Thanks for your time,
>>>>>Hans
>>>>>
>>>>>PS. I have to end with a perhaps naïve question: What
>>>
>>>exactly is meant
>>>
>>>>>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't
>>>>>figure it out.
>>>>>
>>>>>[1] http://incubator.apache.org/tsik
>>>>>[2] http://incubator.apache.org/tsik/roadmap.html
>>>>>[3]
>>>>>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508
>>>
>>>.mbox/%3C5
>>>
>>>>>59c463d050831142314dacd7e@mail.gmail.com%3E
>>>>>
>>>>>------------------------------------------------------------
>>>
>>>---------
>>>
>>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Refactoring (Re: WSS4J future)
Posted by Werner Dittmann <We...@t-online.de>.
Dims, all,
+1 for #2 below. I would like to have a well structured XML
file that defines all necessary parameters. Using the "flat"
parameter structure of the WSDDs is IMO not flexible enough.
But I would also like to avoid the "parsing the parameter file
for every request" option. Thus we need to have a place where
to anchor the parsed parameters. This anchor should be soemwhere
in the Axis / JAX-RPC SOAP engine. IMHO we cant do it in the
handlers themself because we have no control who and when the
handler get instantiated and how long they live.
Any ideas?
Second topic: is there already a XML format defined that we
could use to define our parameter settings? Does somebody has
an link or so?
Regards,
Werner
Davanum Srinivas wrote:
> Hans, Werner,
>
> I've refactored a bunch of stuff and added a package called processors
> (for processing dom elements that are encountered by the security
> engine) and actions (things that the user has asked the handler to
> do). Could you guys please take a look? and comment? if it shows
> promise i'll do more work when i get a change. Basically it breaks up
> all the stuff into pieces that are loaded when needed (trying to get a
> handle on #1 below)
>
> #2, wsdd's how services are configured in Axis. If we can write a
> WS-SecurityPolicy Processor, we could replace the complicated
> parameter stuff with a link to a single xml in the wsdd.
>
> #3, Folks pick up what they need and put them together. Kirill is
> demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM (Axis1.X, WSS4J,
> Sandesha, Addressing) more on that later :)
>
> thanks,
> dims
>
>
> On 9/13/05, Granqvist, Hans <hg...@verisign.com> wrote:
>
>>>>I would really like to have a discussion/exchange of ideas how to
>>>>improve the code, add a "plugin" feature for various functions like
>>>>SAML, Kerberos, etc (Dims asked about that a time ago).
>>
>>First of all: I don't want to step on anyone's toes. Don't get
>>discouraged. Just some ideas and thoughts below.
>>
>>1) I'd like to see if I can re-architect a few areas of WSS4J and
>>make some portions less coupled. Some of the handlers seem
>>monolithic and too hard to understand. The code is somewhat too
>>relaxed in syntax, javadoc, etc., and makes a sloppy impression
>>(which is bad since the code doesn't seem that bad once you look
>>closer, but it probably scares off potential developers they way
>>it looks now.)
>>
>>2) There is something about the wsdd files that bothers me, but I
>>can't figure out if it's a vestige of Axis. Anyone feel the same?
>>Quite a few questions to the list relate to these deployment files.
>>All the "XML situps" seem error prone and a security risk, too.
>>These files could be pre-packaged and signed, and somehow mapped
>>to policies, perhaps.
>>
>>3) I lack a "user's vision" how all the ws.apache.org projects work
>>together. For example, if I want to use, say, WS-Trust, would I (as
>>a WSS4J user) collate the various ws.apache.org project JARs that
>>WS-Trust depend on, or would there be separate deployment steps to
>>get, say, the WS-Addressing parts needed? There seems too much
>>fragmentation. But perhaps I exaggerate?
>>
>>Okay, my chin is out. Feel free to pound on it :)
>>
>>Hans
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>>Sent: Monday, September 12, 2005 11:48 PM
>>>To: Granqvist, Hans
>>>Cc: wss4j-dev@ws.apache.org
>>>Subject: Re: WSS4J future
>>>
>>>Hans,
>>>
>>>just forgot:
>>>the WSS4J core library does not depend on Axis. It is
>>>possible to use other SOAP stacks / SOAP engines as well.
>>>AFAIK there are other implementations for other SOAP engines.
>>>
>>>Only the handlers depend on the underlying SOAP engines.
>>>Currently we provide handlers for Axis and JAX-RPC SOAP
>>>engines. The handlers use the WSS4J library / methods.
>>>
>>>This decoupling of core and handler was one of the first
>>>steps during WSS4J development.
>>>
>>>Regards,
>>>Werner
>>>
>>>Werner Dittmann wrote:
>>>
>>>>Hans,
>>>>
>>>>ther are is real roadmap / versions planning. We try to
>>>
>>>keep up with
>>>
>>>>the specs, interop problems with .Net etc. The whole developer team
>>>>for the core are just 2-3 people, all really part time. Thus it was
>>>>just not possible to do more as to keep up with specs and interop
>>>>problems.
>>>>
>>>>For sure there are some areas that need code improvements, in
>>>>partiular the whole error/exception handling needs to be
>>>
>>>cleaned up.
>>>
>>>>Also to make it more compliant the the specs in terms of
>>>
>>>error code, messages etc.
>>>
>>>>Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their
>>>>project, maybe Dims as "the master" :-) can give you more info.
>>>>
>>>>Sandbox: Dims did it and put code in it that is not yet part of the
>>>>official WSS4J release (Trust, Secure Conversation). See the README.
>>>>
>>>>As for DOM centic: yes, you are right. IMHO it is not easy
>>>
>>>to use SAX
>>>
>>>>or pull parsers or other optimizations. Several reasons:
>>>>- during Security processing you often must alter existing elements,
>>>> e.g. in the Body, replace elements, insert new elements
>>>>- The scurity elements need to refer to elements in the Body and
>>>> elsewhere.
>>>>- if you need to sign/encrypt you need the real content and, in case
>>>> of encryption, replace it with the encrypted data.
>>>>- depeding on the order of the security actions to perform you may
>>>> again need to reference / sign these elements
>>>>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>>>> also based on DOM.
>>>>
>>>>Many of these things need a "full tree" to be able to
>>>
>>>navigate inside
>>>
>>>>the tree and modify it where needed.
>>>>
>>>>While it may be possible to rewrite WSS4J to use SAX or
>>>
>>>pull parsers
>>>
>>>>it will introduce additional logic to keep track of references,
>>>>element replacements etc. These functions are available in
>>>
>>>DOM. Thus,
>>>
>>>>IMHO, it would not be simpler - maybe even more complex
>>>
>>>from the WSS4J
>>>
>>>>code point of view.
>>>>
>>>>Thoughts?
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>Granqvist, Hans wrote:
>>>>
>>>>
>>>>>Hi developers,
>>>>>
>>>>>I currently work on the a ws.apache.org incubation project
>>>
>>>[1], and I
>>>
>>>>>want to see how I can contribute to wss4j and ws.apache.org.
>>>>>
>>>>>I've spent some time going through the wss4j source, but I lack an
>>>>>overall view of what you all currently work on, or what you plan to
>>>>>work on, now and in the close future. Is there a roadmap?
>>>
>>>Is there
>>>
>>>>>also a list of who's involved with which standards bodies
>>>
>>>development?
>>>
>>>>>Are there areas in the wss4j code that you feel could be improved?
>>>>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but
>>>>>I'd like to know what you think the real itches are (there must be
>>>>>some? ;)
>>>>>
>>>>>Are there any ideas in the core/plugin/addon structure of
>>>
>>>[1] that you
>>>
>>>>>think makes sense to use/work on in wss4j? (Please note that the
>>>>>javadocs link in [1] is somewhat out-of-date currently.)
>>>>>
>>>>>What does Axis2 mean for the wss4j development? Are there Axis v1
>>>>>areas of wss4j that I should not waste time on because of something
>>>>>else, something better in the works? I'd hate to start working on
>>>>>something that is slated to go away.
>>>>>
>>>>>Part of my personal drive is to try to implement the
>>>
>>>identity system
>>>
>>>>>(see more info in [2]) and that would involve some work implementing
>>>>>WS-* standards, plus potentially some interesting end-user APIs.
>>>>>Previous emails [3] on for example WS-Trust sound promising, but
>>>>>directions are somewhat unclear. Comments, ideas, prioritizations,
>>>>>etc., mucho welcome.
>>>>>
>>>>>The various ws.apache.org projects working together in a non-Axis
>>>>>setting -- is that concept out-of-scope?
>>>>>
>>>>>wss4j is currently quite DOM-centric. Do we want to get away from
>>>>>that? SAX, push-pull, etc.?
>>>>>
>>>>>
>>>>>Thanks for your time,
>>>>>Hans
>>>>>
>>>>>PS. I have to end with a perhaps naïve question: What
>>>
>>>exactly is meant
>>>
>>>>>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't
>>>>>figure it out.
>>>>>
>>>>>[1] http://incubator.apache.org/tsik
>>>>>[2] http://incubator.apache.org/tsik/roadmap.html
>>>>>[3]
>>>>>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508
>>>
>>>.mbox/%3C5
>>>
>>>>>59c463d050831142314dacd7e@mail.gmail.com%3E
>>>>>
>>>>>------------------------------------------------------------
>>>
>>>---------
>>>
>>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Refactoring (Re: WSS4J future)
Posted by Werner Dittmann <We...@t-online.de>.
Dims, all,
+1 for #2 below. I would like to have a well structured XML
file that defines all necessary parameters. Using the "flat"
parameter structure of the WSDDs is IMO not flexible enough.
But I would also like to avoid the "parsing the parameter file
for every request" option. Thus we need to have a place where
to anchor the parsed parameters. This anchor should be soemwhere
in the Axis / JAX-RPC SOAP engine. IMHO we cant do it in the
handlers themself because we have no control who and when the
handler get instantiated and how long they live.
Any ideas?
Second topic: is there already a XML format defined that we
could use to define our parameter settings? Does somebody has
an link or so?
Regards,
Werner
Davanum Srinivas wrote:
> Hans, Werner,
>
> I've refactored a bunch of stuff and added a package called processors
> (for processing dom elements that are encountered by the security
> engine) and actions (things that the user has asked the handler to
> do). Could you guys please take a look? and comment? if it shows
> promise i'll do more work when i get a change. Basically it breaks up
> all the stuff into pieces that are loaded when needed (trying to get a
> handle on #1 below)
>
> #2, wsdd's how services are configured in Axis. If we can write a
> WS-SecurityPolicy Processor, we could replace the complicated
> parameter stuff with a link to a single xml in the wsdd.
>
> #3, Folks pick up what they need and put them together. Kirill is
> demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM (Axis1.X, WSS4J,
> Sandesha, Addressing) more on that later :)
>
> thanks,
> dims
>
>
> On 9/13/05, Granqvist, Hans <hg...@verisign.com> wrote:
>
>>>>I would really like to have a discussion/exchange of ideas how to
>>>>improve the code, add a "plugin" feature for various functions like
>>>>SAML, Kerberos, etc (Dims asked about that a time ago).
>>
>>First of all: I don't want to step on anyone's toes. Don't get
>>discouraged. Just some ideas and thoughts below.
>>
>>1) I'd like to see if I can re-architect a few areas of WSS4J and
>>make some portions less coupled. Some of the handlers seem
>>monolithic and too hard to understand. The code is somewhat too
>>relaxed in syntax, javadoc, etc., and makes a sloppy impression
>>(which is bad since the code doesn't seem that bad once you look
>>closer, but it probably scares off potential developers they way
>>it looks now.)
>>
>>2) There is something about the wsdd files that bothers me, but I
>>can't figure out if it's a vestige of Axis. Anyone feel the same?
>>Quite a few questions to the list relate to these deployment files.
>>All the "XML situps" seem error prone and a security risk, too.
>>These files could be pre-packaged and signed, and somehow mapped
>>to policies, perhaps.
>>
>>3) I lack a "user's vision" how all the ws.apache.org projects work
>>together. For example, if I want to use, say, WS-Trust, would I (as
>>a WSS4J user) collate the various ws.apache.org project JARs that
>>WS-Trust depend on, or would there be separate deployment steps to
>>get, say, the WS-Addressing parts needed? There seems too much
>>fragmentation. But perhaps I exaggerate?
>>
>>Okay, my chin is out. Feel free to pound on it :)
>>
>>Hans
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>>Sent: Monday, September 12, 2005 11:48 PM
>>>To: Granqvist, Hans
>>>Cc: wss4j-dev@ws.apache.org
>>>Subject: Re: WSS4J future
>>>
>>>Hans,
>>>
>>>just forgot:
>>>the WSS4J core library does not depend on Axis. It is
>>>possible to use other SOAP stacks / SOAP engines as well.
>>>AFAIK there are other implementations for other SOAP engines.
>>>
>>>Only the handlers depend on the underlying SOAP engines.
>>>Currently we provide handlers for Axis and JAX-RPC SOAP
>>>engines. The handlers use the WSS4J library / methods.
>>>
>>>This decoupling of core and handler was one of the first
>>>steps during WSS4J development.
>>>
>>>Regards,
>>>Werner
>>>
>>>Werner Dittmann wrote:
>>>
>>>>Hans,
>>>>
>>>>ther are is real roadmap / versions planning. We try to
>>>
>>>keep up with
>>>
>>>>the specs, interop problems with .Net etc. The whole developer team
>>>>for the core are just 2-3 people, all really part time. Thus it was
>>>>just not possible to do more as to keep up with specs and interop
>>>>problems.
>>>>
>>>>For sure there are some areas that need code improvements, in
>>>>partiular the whole error/exception handling needs to be
>>>
>>>cleaned up.
>>>
>>>>Also to make it more compliant the the specs in terms of
>>>
>>>error code, messages etc.
>>>
>>>>Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their
>>>>project, maybe Dims as "the master" :-) can give you more info.
>>>>
>>>>Sandbox: Dims did it and put code in it that is not yet part of the
>>>>official WSS4J release (Trust, Secure Conversation). See the README.
>>>>
>>>>As for DOM centic: yes, you are right. IMHO it is not easy
>>>
>>>to use SAX
>>>
>>>>or pull parsers or other optimizations. Several reasons:
>>>>- during Security processing you often must alter existing elements,
>>>> e.g. in the Body, replace elements, insert new elements
>>>>- The scurity elements need to refer to elements in the Body and
>>>> elsewhere.
>>>>- if you need to sign/encrypt you need the real content and, in case
>>>> of encryption, replace it with the encrypted data.
>>>>- depeding on the order of the security actions to perform you may
>>>> again need to reference / sign these elements
>>>>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>>>> also based on DOM.
>>>>
>>>>Many of these things need a "full tree" to be able to
>>>
>>>navigate inside
>>>
>>>>the tree and modify it where needed.
>>>>
>>>>While it may be possible to rewrite WSS4J to use SAX or
>>>
>>>pull parsers
>>>
>>>>it will introduce additional logic to keep track of references,
>>>>element replacements etc. These functions are available in
>>>
>>>DOM. Thus,
>>>
>>>>IMHO, it would not be simpler - maybe even more complex
>>>
>>>from the WSS4J
>>>
>>>>code point of view.
>>>>
>>>>Thoughts?
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>Granqvist, Hans wrote:
>>>>
>>>>
>>>>>Hi developers,
>>>>>
>>>>>I currently work on the a ws.apache.org incubation project
>>>
>>>[1], and I
>>>
>>>>>want to see how I can contribute to wss4j and ws.apache.org.
>>>>>
>>>>>I've spent some time going through the wss4j source, but I lack an
>>>>>overall view of what you all currently work on, or what you plan to
>>>>>work on, now and in the close future. Is there a roadmap?
>>>
>>>Is there
>>>
>>>>>also a list of who's involved with which standards bodies
>>>
>>>development?
>>>
>>>>>Are there areas in the wss4j code that you feel could be improved?
>>>>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but
>>>>>I'd like to know what you think the real itches are (there must be
>>>>>some? ;)
>>>>>
>>>>>Are there any ideas in the core/plugin/addon structure of
>>>
>>>[1] that you
>>>
>>>>>think makes sense to use/work on in wss4j? (Please note that the
>>>>>javadocs link in [1] is somewhat out-of-date currently.)
>>>>>
>>>>>What does Axis2 mean for the wss4j development? Are there Axis v1
>>>>>areas of wss4j that I should not waste time on because of something
>>>>>else, something better in the works? I'd hate to start working on
>>>>>something that is slated to go away.
>>>>>
>>>>>Part of my personal drive is to try to implement the
>>>
>>>identity system
>>>
>>>>>(see more info in [2]) and that would involve some work implementing
>>>>>WS-* standards, plus potentially some interesting end-user APIs.
>>>>>Previous emails [3] on for example WS-Trust sound promising, but
>>>>>directions are somewhat unclear. Comments, ideas, prioritizations,
>>>>>etc., mucho welcome.
>>>>>
>>>>>The various ws.apache.org projects working together in a non-Axis
>>>>>setting -- is that concept out-of-scope?
>>>>>
>>>>>wss4j is currently quite DOM-centric. Do we want to get away from
>>>>>that? SAX, push-pull, etc.?
>>>>>
>>>>>
>>>>>Thanks for your time,
>>>>>Hans
>>>>>
>>>>>PS. I have to end with a perhaps naïve question: What
>>>
>>>exactly is meant
>>>
>>>>>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't
>>>>>figure it out.
>>>>>
>>>>>[1] http://incubator.apache.org/tsik
>>>>>[2] http://incubator.apache.org/tsik/roadmap.html
>>>>>[3]
>>>>>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508
>>>
>>>.mbox/%3C5
>>>
>>>>>59c463d050831142314dacd7e@mail.gmail.com%3E
>>>>>
>>>>>------------------------------------------------------------
>>>
>>>---------
>>>
>>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org