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 "Granqvist, Hans" <hg...@verisign.com> on 2005/09/12 18:55:28 UTC

WSS4J future

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/%3C559c463d050831142314dacd7e@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


Re: WSS4J future

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

comments below,

Werner Dittmann wrote:

>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
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>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.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>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/%3C559c463d050831142314dacd7e@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
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: WSS4J future

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

comments below,

Werner Dittmann wrote:

>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
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>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.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>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/%3C559c463d050831142314dacd7e@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
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: WSS4J future (resent to tsik-dev@ws.apache.org)

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

comments below,

Werner Dittmann wrote:

>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
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>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.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>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/%3C559c463d050831142314dacd7e@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
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: WSS4J future (resent to tsik-dev@ws.apache.org)

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

comments below,

Werner Dittmann wrote:

>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
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>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.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>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/%3C559c463d050831142314dacd7e@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
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: WSS4J future

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Werner,

> though I never looked at AXION yet (need to do it :-)  )
> not only XML-Security and WSS4J nut also Xalan needs
> to sit on top of this because all use DOM. Xalan provides
> XPath to XML-SEC but Xalan also implemets a XSLT engine.

We already can do XPath over AXIOM using Jaxen .. so if that's the only
need for Xalan we can do without it. 

> Also, in such a case we need to have a specific XML-Sec and
> Xalan implementation because not every one who uses these
> libraries will or can also use AXIOM.

Absolutely. 

What I'd like to see is if someone is using Axis2, they get the fastest
possible WS-Security (and Trust, SecureConv etc.) under the sun. Whether
that means it uses a standard API like DOM or not is not a requirement
in my mind :).

In any case, we will have a DOM wrapper for AXIOM too if someone wants
to do it that way (and pay the perf cost).

Sanjiva.



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


Re: WSS4J future

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Werner,

> though I never looked at AXION yet (need to do it :-)  )
> not only XML-Security and WSS4J nut also Xalan needs
> to sit on top of this because all use DOM. Xalan provides
> XPath to XML-SEC but Xalan also implemets a XSLT engine.

We already can do XPath over AXIOM using Jaxen .. so if that's the only
need for Xalan we can do without it. 

> Also, in such a case we need to have a specific XML-Sec and
> Xalan implementation because not every one who uses these
> libraries will or can also use AXIOM.

Absolutely. 

What I'd like to see is if someone is using Axis2, they get the fastest
possible WS-Security (and Trust, SecureConv etc.) under the sun. Whether
that means it uses a standard API like DOM or not is not a requirement
in my mind :).

In any case, we will have a DOM wrapper for AXIOM too if someone wants
to do it that way (and pay the perf cost).

Sanjiva.



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


Re: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
Sanjiva,

though I never looked at AXION yet (need to do it :-)  )
not only XML-Security and WSS4J nut also Xalan needs
to sit on top of this because all use DOM. Xalan provides
XPath to XML-SEC but Xalan also implemets a XSLT engine.

Also, in such a case we need to have a specific XML-Sec and
Xalan implementation because not every one who uses these
libraries will or can also use AXIOM.


Regards,
Werner

Sanjiva Weerawarana wrote:
> On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
> 
>>>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.
> 
> 
> I wonder whether its possible to build XML Security and WSS4J on top of
> AXIOM directly. That would be great because currently in Axis2 we
> convert the trees to be able to run WSS4J, which obviously sucks.
> 
> Sanjiva.
> 
> 
> 
> ---------------------------------------------------------------------
> 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: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
Sanjiva,

though I never looked at AXION yet (need to do it :-)  )
not only XML-Security and WSS4J nut also Xalan needs
to sit on top of this because all use DOM. Xalan provides
XPath to XML-SEC but Xalan also implemets a XSLT engine.

Also, in such a case we need to have a specific XML-Sec and
Xalan implementation because not every one who uses these
libraries will or can also use AXIOM.


Regards,
Werner

Sanjiva Weerawarana wrote:
> On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
> 
>>>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.
> 
> 
> I wonder whether its possible to build XML Security and WSS4J on top of
> AXIOM directly. That would be great because currently in Axis2 we
> convert the trees to be able to run WSS4J, which obviously sucks.
> 
> Sanjiva.
> 
> 
> 
> ---------------------------------------------------------------------
> 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: WSS4J future

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

reply below.

Sanjiva Weerawarana wrote:

>On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
>  
>
>>>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.
>>>      
>>>
>
>I wonder whether its possible to build XML Security and WSS4J on top of
>AXIOM directly. That would be great because currently in Axis2 we
>convert the trees to be able to run WSS4J, which obviously sucks.
>  
>
i think that may help (AXIOM has smaller memory footprint and do not 
build XML tree when not accessed) but it is not enough: you need to 
compute/check signature digest (or encrypt/decrypt)  in streaming mode 
and if you access it as AXIOM you would materialize in memory lot of 
Infoset instead you need a lower level character stream that is doing 
streaming c14n over xml even stream (selected with streamable XPath).

thanks,

alek

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


-- 
The best way to predict the future is to invent it - Alan Kay


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


Re: WSS4J future

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

reply below.

Sanjiva Weerawarana wrote:

>On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
>  
>
>>>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.
>>>      
>>>
>
>I wonder whether its possible to build XML Security and WSS4J on top of
>AXIOM directly. That would be great because currently in Axis2 we
>convert the trees to be able to run WSS4J, which obviously sucks.
>  
>
i think that may help (AXIOM has smaller memory footprint and do not 
build XML tree when not accessed) but it is not enough: you need to 
compute/check signature digest (or encrypt/decrypt)  in streaming mode 
and if you access it as AXIOM you would materialize in memory lot of 
Infoset instead you need a lower level character stream that is doing 
streaming c14n over xml even stream (selected with streamable XPath).

thanks,

alek

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


-- 
The best way to predict the future is to invent it - Alan Kay


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


Re: WSS4J future

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
> > 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.

I wonder whether its possible to build XML Security and WSS4J on top of
AXIOM directly. That would be great because currently in Axis2 we
convert the trees to be able to run WSS4J, which obviously sucks.

Sanjiva.



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


Re: WSS4J future

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-09-13 at 08:48 +0200, Werner Dittmann wrote:
> > 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.

I wonder whether its possible to build XML Security and WSS4J on top of
AXIOM directly. That would be great because currently in Axis2 we
convert the trees to be able to run WSS4J, which obviously sucks.

Sanjiva.



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


Re: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
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.
> 
> 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).
> 
> 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/%3C559c463d050831142314dacd7e@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


Re: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
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.
> 
> 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).
> 
> 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/%3C559c463d050831142314dacd7e@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


Re: WSS4J future (resent to tsik-dev@ws.apache.org)

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
hi,

comments below,

Werner Dittmann wrote:

>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
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>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.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>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/%3C559c463d050831142314dacd7e@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
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Re: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
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.

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).

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/%3C559c463d050831142314dacd7e@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


Re: WSS4J future

Posted by Werner Dittmann <We...@t-online.de>.
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.

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).

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/%3C559c463d050831142314dacd7e@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