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 Yves Langisch <li...@langisch.ch> on 2004/08/25 18:58:55 UTC
[WSS4J] client handler chaining with different actors
All,
On client-side I use a handler chain with following actions:
handler1 = Timestamp Signature NoSerialization
handler2 = Encrypt
For both of them I define a different actor in order to get TWO security
headers but the message on the wire always contains only one header
(with actor=handler2actor) with all the information (ts, sig, enc) in
it. I looked through the source and found the location where this
'overwriting' or 'merging' happens: The method insertSecurityHeader in
the WSBaseMessage class seems to be 'actor-aware'. But inside of this
method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
which should add oder supplement a header for a specific actor. But if
there is already a security header it always returns this one instead of
creating a new one if the actor differs.
Am I understanding anything wrong or is this a bug?
Regards,
Yves
PS. I'm using the latest source.
Re: [WSS4J] client handler chaining with different actors
Posted by Yves Langisch <li...@langisch.ch>.
Werner,
I'll check it again tomorrow morning and if I still think that it is a
bug I'll provide a patch ;-)
Regards,
Yves
Werner Dittmann wrote:
>Yes,
>could be a real bug :-). This "chaining was not very well tested (at least
>not
>with different actors). I need to update my source tree here and have a
>look.
>Appreciate if you can just send a patch or something like that :-).
>
>Regards,
>Werner
>
>----- Original Message -----
>From: "Yves Langisch" <li...@langisch.ch>
>To: <fx...@ws.apache.org>
>Sent: Wednesday, August 25, 2004 6:58 PM
>Subject: [WSS4J] client handler chaining with different actors
>
>
>
>
>>All,
>>
>>On client-side I use a handler chain with following actions:
>>
>>handler1 = Timestamp Signature NoSerialization
>>handler2 = Encrypt
>>
>>For both of them I define a different actor in order to get TWO security
>>headers but the message on the wire always contains only one header
>>(with actor=handler2actor) with all the information (ts, sig, enc) in
>>it. I looked through the source and found the location where this
>>'overwriting' or 'merging' happens: The method insertSecurityHeader in
>>the WSBaseMessage class seems to be 'actor-aware'. But inside of this
>>method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
>>which should add oder supplement a header for a specific actor. But if
>>there is already a security header it always returns this one instead of
>>creating a new one if the actor differs.
>>
>>Am I understanding anything wrong or is this a bug?
>>
>>Regards,
>>Yves
>>
>>PS. I'm using the latest source.
>>
>>
>
>
>
Re: [WSS4J] client handler chaining with different actors
Posted by Davanum Srinivas <da...@gmail.com>.
Yves,
i can do it...but please create a bug report and upload the diff to
JIRA (my email client munges the text file).
http://issues.apache.org/jira.
thanks,
dims
On Mon, 30 Aug 2004 09:12:04 +0200, Yves Langisch <li...@langisch.ch> wrote:
> Werner,
>
> Did you already have time to check the patch?
>
> Regards,
> Yves
>
>
>
> Yves Langisch wrote:
>
> > Werner,
> >
> > Here's the diff of my patch. Can you please review it:
> >
> > cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic diff -u
> >
> > cvs server: Diffing .
> > cvs server: Diffing org
> > cvs server: Diffing org/apache
> > cvs server: Diffing org/apache/ws
> > cvs server: Diffing org/apache/ws/axis
> > cvs server: Diffing org/apache/ws/axis/security
> > cvs server: Diffing org/apache/ws/axis/security/conversation
> > cvs server: Diffing org/apache/ws/axis/security/saml
> > cvs server: Diffing org/apache/ws/axis/security/trust
> > cvs server: Diffing org/apache/ws/axis/security/util
> > cvs server: Diffing org/apache/ws/security
> > cvs server: Diffing org/apache/ws/security/components
> > cvs server: Diffing org/apache/ws/security/components/crypto
> > cvs server: Diffing org/apache/ws/security/conversation
> > cvs server: Diffing org/apache/ws/security/conversation/dkAlgo
> > cvs server: Diffing org/apache/ws/security/conversation/message
> > cvs server: Diffing org/apache/ws/security/conversation/message/info
> > cvs server: Diffing org/apache/ws/security/conversation/message/token
> > cvs server: Diffing org/apache/ws/security/conversation/sessions
> > cvs server: Diffing org/apache/ws/security/handler
> > cvs server: Diffing org/apache/ws/security/message
> > Index: org/apache/ws/security/message/WSBaseMessage.java
> > ===================================================================
> > RCS file:
> > /home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/message/WSBaseMessage.java,v
> >
> > retrieving revision 1.12
> > diff -u -r1.12 WSBaseMessage.java
> > --- org/apache/ws/security/message/WSBaseMessage.java 9 Aug 2004
> > 17:53:45 -0000 1.12
> > +++ org/apache/ws/security/message/WSBaseMessage.java 26 Aug 2004
> > 08:56:41 -0000
> > @@ -254,6 +254,7 @@
> > WSSecurityUtil.findWsseSecurityHeaderBlock(wssConfig,
> > doc,
> > doc.getDocumentElement(),
> > + actor,
> > true);
> >
> > String soapPrefix =
> > cvs server: Diffing org/apache/ws/security/message/token
> > cvs server: Diffing org/apache/ws/security/saml
> > cvs server: Diffing org/apache/ws/security/transform
> > cvs server: Diffing org/apache/ws/security/trust
> > cvs server: Diffing org/apache/ws/security/trust/issue
> > cvs server: Diffing org/apache/ws/security/trust/message
> > cvs server: Diffing org/apache/ws/security/trust/message/Info
> > cvs server: Diffing org/apache/ws/security/trust/message/token
> > cvs server: Diffing org/apache/ws/security/trust/renew
> > cvs server: Diffing org/apache/ws/security/trust/request
> > cvs server: Diffing org/apache/ws/security/trust/validate
> > cvs server: Diffing org/apache/ws/security/trust/verify
> > cvs server: Diffing org/apache/ws/security/trust2
> > cvs server: Diffing org/apache/ws/security/trust2/exception
> > cvs server: Diffing org/apache/ws/security/trust2/samples
> > cvs server: Diffing org/apache/ws/security/trust2/serialization
> > cvs server: Diffing org/apache/ws/security/util
> > Index: org/apache/ws/security/util/WSSecurityUtil.java
> > ===================================================================
> > RCS file:
> > /home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/util/WSSecurityUtil.java,v
> >
> > retrieving revision 1.20
> > diff -u -r1.20 WSSecurityUtil.java
> > --- org/apache/ws/security/util/WSSecurityUtil.java 9 Aug 2004
> > 17:53:47 -0000 1.20
> > +++ org/apache/ws/security/util/WSSecurityUtil.java 26 Aug 2004
> > 08:56:41 -0000
> > @@ -651,7 +651,7 @@
> > }
> >
> > /**
> > - * find the ws-security header block
> > + * find the first ws-security header block
> > * <p/>
> > *
> > * @param doc
> > @@ -660,24 +660,35 @@
> > * @return
> > */
> > public static Element findWsseSecurityHeaderBlock(WSSConfig
> > wssConfig, Document doc, Element envelope, boolean doCreate) {
> > + return findWsseSecurityHeaderBlock(wssConfig, doc, envelope,
> > null, doCreate);
> > + }
> > +
> > + /**
> > + * find a ws-security header block for a given actor
> > + * <p/>
> > + *
> > + * @param doc
> > + * @param envelope
> > + * @param actor
> > + * @param doCreate
> > + * @return
> > + */
> > + public static Element findWsseSecurityHeaderBlock(WSSConfig
> > wssConfig,
> > + Document doc,
> > + Element envelope,
> > + String actor,
> > + boolean
> > doCreate) {
> > SOAPConstants sc = getSOAPConstants(envelope);
> > + Element wsseSecurity = getSecurityHeader(wssConfig, doc,
> > actor, sc);
> > + if (wsseSecurity != null) {
> > + return wsseSecurity;
> > + }
> > Element header = findChildElement(envelope,
> > sc.getEnvelopeURI(), sc.getHeaderQName().getLocalPart());
> > if (header == null) {
> > if (doCreate) {
> > header = createElementInSameNamespace(envelope,
> > sc.getHeaderQName().getLocalPart());
> > header = prependChildElement(doc, envelope, header,
> > true);
> > }
> > - }
> > - Element wsseSecurity = null;
> > - if (wssConfig.getProcessNonCompliantMessages()) {
> > - for (int i = 0; wsseSecurity == null && i <
> > WSConstants.WSSE_NS_ARRAY.length; ++i) {
> > - wsseSecurity = findChildElement(header,
> > WSConstants.WSSE_NS_ARRAY[i], "Security");
> > - }
> > - } else {
> > - wsseSecurity = findChildElement(header,
> > wssConfig.getWsseNS(), "Security");
> > - }
> > - if (wsseSecurity != null) {
> > - return wsseSecurity;
> > }
> > if (doCreate) {
> > wsseSecurity =
> > header.getOwnerDocument().createElementNS(wssConfig.getWsseNS(),
> > "wsse:Security");
> >
> > Regards,
> > Yves
> >
> > Werner Dittmann wrote:
> >
> >> Yes,
> >> could be a real bug :-). This "chaining was not very well tested (at
> >> least
> >> not
> >> with different actors). I need to update my source tree here and have a
> >> look.
> >> Appreciate if you can just send a patch or something like that :-).
> >>
> >> Regards,
> >> Werner
> >>
> >> ----- Original Message -----
> >> From: "Yves Langisch" <li...@langisch.ch>
> >> To: <fx...@ws.apache.org>
> >> Sent: Wednesday, August 25, 2004 6:58 PM
> >> Subject: [WSS4J] client handler chaining with different actors
> >>
> >>
> >>
> >>
> >>> All,
> >>>
> >>> On client-side I use a handler chain with following actions:
> >>>
> >>> handler1 = Timestamp Signature NoSerialization
> >>> handler2 = Encrypt
> >>>
> >>> For both of them I define a different actor in order to get TWO
> >>> security
> >>> headers but the message on the wire always contains only one header
> >>> (with actor=handler2actor) with all the information (ts, sig, enc) in
> >>> it. I looked through the source and found the location where this
> >>> 'overwriting' or 'merging' happens: The method insertSecurityHeader in
> >>> the WSBaseMessage class seems to be 'actor-aware'. But inside of this
> >>> method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
> >>> which should add oder supplement a header for a specific actor. But if
> >>> there is already a security header it always returns this one
> >>> instead of
> >>> creating a new one if the actor differs.
> >>>
> >>> Am I understanding anything wrong or is this a bug?
> >>>
> >>> Regards,
> >>> Yves
> >>>
> >>> PS. I'm using the latest source.
> >>>
> >>
> >>
> >>
> >>
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [WSS4J] client handler chaining with different actors
Posted by Yves Langisch <li...@langisch.ch>.
Werner,
Did you already have time to check the patch?
Regards,
Yves
Yves Langisch wrote:
> Werner,
>
> Here's the diff of my patch. Can you please review it:
>
> cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic diff -u
>
> cvs server: Diffing .
> cvs server: Diffing org
> cvs server: Diffing org/apache
> cvs server: Diffing org/apache/ws
> cvs server: Diffing org/apache/ws/axis
> cvs server: Diffing org/apache/ws/axis/security
> cvs server: Diffing org/apache/ws/axis/security/conversation
> cvs server: Diffing org/apache/ws/axis/security/saml
> cvs server: Diffing org/apache/ws/axis/security/trust
> cvs server: Diffing org/apache/ws/axis/security/util
> cvs server: Diffing org/apache/ws/security
> cvs server: Diffing org/apache/ws/security/components
> cvs server: Diffing org/apache/ws/security/components/crypto
> cvs server: Diffing org/apache/ws/security/conversation
> cvs server: Diffing org/apache/ws/security/conversation/dkAlgo
> cvs server: Diffing org/apache/ws/security/conversation/message
> cvs server: Diffing org/apache/ws/security/conversation/message/info
> cvs server: Diffing org/apache/ws/security/conversation/message/token
> cvs server: Diffing org/apache/ws/security/conversation/sessions
> cvs server: Diffing org/apache/ws/security/handler
> cvs server: Diffing org/apache/ws/security/message
> Index: org/apache/ws/security/message/WSBaseMessage.java
> ===================================================================
> RCS file:
> /home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/message/WSBaseMessage.java,v
>
> retrieving revision 1.12
> diff -u -r1.12 WSBaseMessage.java
> --- org/apache/ws/security/message/WSBaseMessage.java 9 Aug 2004
> 17:53:45 -0000 1.12
> +++ org/apache/ws/security/message/WSBaseMessage.java 26 Aug 2004
> 08:56:41 -0000
> @@ -254,6 +254,7 @@
> WSSecurityUtil.findWsseSecurityHeaderBlock(wssConfig,
> doc,
> doc.getDocumentElement(),
> + actor,
> true);
>
> String soapPrefix =
> cvs server: Diffing org/apache/ws/security/message/token
> cvs server: Diffing org/apache/ws/security/saml
> cvs server: Diffing org/apache/ws/security/transform
> cvs server: Diffing org/apache/ws/security/trust
> cvs server: Diffing org/apache/ws/security/trust/issue
> cvs server: Diffing org/apache/ws/security/trust/message
> cvs server: Diffing org/apache/ws/security/trust/message/Info
> cvs server: Diffing org/apache/ws/security/trust/message/token
> cvs server: Diffing org/apache/ws/security/trust/renew
> cvs server: Diffing org/apache/ws/security/trust/request
> cvs server: Diffing org/apache/ws/security/trust/validate
> cvs server: Diffing org/apache/ws/security/trust/verify
> cvs server: Diffing org/apache/ws/security/trust2
> cvs server: Diffing org/apache/ws/security/trust2/exception
> cvs server: Diffing org/apache/ws/security/trust2/samples
> cvs server: Diffing org/apache/ws/security/trust2/serialization
> cvs server: Diffing org/apache/ws/security/util
> Index: org/apache/ws/security/util/WSSecurityUtil.java
> ===================================================================
> RCS file:
> /home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/util/WSSecurityUtil.java,v
>
> retrieving revision 1.20
> diff -u -r1.20 WSSecurityUtil.java
> --- org/apache/ws/security/util/WSSecurityUtil.java 9 Aug 2004
> 17:53:47 -0000 1.20
> +++ org/apache/ws/security/util/WSSecurityUtil.java 26 Aug 2004
> 08:56:41 -0000
> @@ -651,7 +651,7 @@
> }
>
> /**
> - * find the ws-security header block
> + * find the first ws-security header block
> * <p/>
> *
> * @param doc
> @@ -660,24 +660,35 @@
> * @return
> */
> public static Element findWsseSecurityHeaderBlock(WSSConfig
> wssConfig, Document doc, Element envelope, boolean doCreate) {
> + return findWsseSecurityHeaderBlock(wssConfig, doc, envelope,
> null, doCreate);
> + }
> +
> + /**
> + * find a ws-security header block for a given actor
> + * <p/>
> + *
> + * @param doc
> + * @param envelope
> + * @param actor
> + * @param doCreate
> + * @return
> + */
> + public static Element findWsseSecurityHeaderBlock(WSSConfig
> wssConfig,
> + Document doc,
> + Element envelope,
> + String actor,
> + boolean
> doCreate) {
> SOAPConstants sc = getSOAPConstants(envelope);
> + Element wsseSecurity = getSecurityHeader(wssConfig, doc,
> actor, sc);
> + if (wsseSecurity != null) {
> + return wsseSecurity;
> + }
> Element header = findChildElement(envelope,
> sc.getEnvelopeURI(), sc.getHeaderQName().getLocalPart());
> if (header == null) {
> if (doCreate) {
> header = createElementInSameNamespace(envelope,
> sc.getHeaderQName().getLocalPart());
> header = prependChildElement(doc, envelope, header,
> true);
> }
> - }
> - Element wsseSecurity = null;
> - if (wssConfig.getProcessNonCompliantMessages()) {
> - for (int i = 0; wsseSecurity == null && i <
> WSConstants.WSSE_NS_ARRAY.length; ++i) {
> - wsseSecurity = findChildElement(header,
> WSConstants.WSSE_NS_ARRAY[i], "Security");
> - }
> - } else {
> - wsseSecurity = findChildElement(header,
> wssConfig.getWsseNS(), "Security");
> - }
> - if (wsseSecurity != null) {
> - return wsseSecurity;
> }
> if (doCreate) {
> wsseSecurity =
> header.getOwnerDocument().createElementNS(wssConfig.getWsseNS(),
> "wsse:Security");
>
> Regards,
> Yves
>
> Werner Dittmann wrote:
>
>> Yes,
>> could be a real bug :-). This "chaining was not very well tested (at
>> least
>> not
>> with different actors). I need to update my source tree here and have a
>> look.
>> Appreciate if you can just send a patch or something like that :-).
>>
>> Regards,
>> Werner
>>
>> ----- Original Message -----
>> From: "Yves Langisch" <li...@langisch.ch>
>> To: <fx...@ws.apache.org>
>> Sent: Wednesday, August 25, 2004 6:58 PM
>> Subject: [WSS4J] client handler chaining with different actors
>>
>>
>>
>>
>>> All,
>>>
>>> On client-side I use a handler chain with following actions:
>>>
>>> handler1 = Timestamp Signature NoSerialization
>>> handler2 = Encrypt
>>>
>>> For both of them I define a different actor in order to get TWO
>>> security
>>> headers but the message on the wire always contains only one header
>>> (with actor=handler2actor) with all the information (ts, sig, enc) in
>>> it. I looked through the source and found the location where this
>>> 'overwriting' or 'merging' happens: The method insertSecurityHeader in
>>> the WSBaseMessage class seems to be 'actor-aware'. But inside of this
>>> method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
>>> which should add oder supplement a header for a specific actor. But if
>>> there is already a security header it always returns this one
>>> instead of
>>> creating a new one if the actor differs.
>>>
>>> Am I understanding anything wrong or is this a bug?
>>>
>>> Regards,
>>> Yves
>>>
>>> PS. I'm using the latest source.
>>>
>>
>>
>>
>>
>
Re: [WSS4J] client handler chaining with different actors
Posted by Yves Langisch <li...@langisch.ch>.
Werner,
Here's the diff of my patch. Can you please review it:
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic diff -u
cvs server: Diffing .
cvs server: Diffing org
cvs server: Diffing org/apache
cvs server: Diffing org/apache/ws
cvs server: Diffing org/apache/ws/axis
cvs server: Diffing org/apache/ws/axis/security
cvs server: Diffing org/apache/ws/axis/security/conversation
cvs server: Diffing org/apache/ws/axis/security/saml
cvs server: Diffing org/apache/ws/axis/security/trust
cvs server: Diffing org/apache/ws/axis/security/util
cvs server: Diffing org/apache/ws/security
cvs server: Diffing org/apache/ws/security/components
cvs server: Diffing org/apache/ws/security/components/crypto
cvs server: Diffing org/apache/ws/security/conversation
cvs server: Diffing org/apache/ws/security/conversation/dkAlgo
cvs server: Diffing org/apache/ws/security/conversation/message
cvs server: Diffing org/apache/ws/security/conversation/message/info
cvs server: Diffing org/apache/ws/security/conversation/message/token
cvs server: Diffing org/apache/ws/security/conversation/sessions
cvs server: Diffing org/apache/ws/security/handler
cvs server: Diffing org/apache/ws/security/message
Index: org/apache/ws/security/message/WSBaseMessage.java
===================================================================
RCS file:
/home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/message/WSBaseMessage.java,v
retrieving revision 1.12
diff -u -r1.12 WSBaseMessage.java
--- org/apache/ws/security/message/WSBaseMessage.java 9 Aug 2004
17:53:45 -0000 1.12
+++ org/apache/ws/security/message/WSBaseMessage.java 26 Aug 2004
08:56:41 -0000
@@ -254,6 +254,7 @@
WSSecurityUtil.findWsseSecurityHeaderBlock(wssConfig,
doc,
doc.getDocumentElement(),
+ actor,
true);
String soapPrefix =
cvs server: Diffing org/apache/ws/security/message/token
cvs server: Diffing org/apache/ws/security/saml
cvs server: Diffing org/apache/ws/security/transform
cvs server: Diffing org/apache/ws/security/trust
cvs server: Diffing org/apache/ws/security/trust/issue
cvs server: Diffing org/apache/ws/security/trust/message
cvs server: Diffing org/apache/ws/security/trust/message/Info
cvs server: Diffing org/apache/ws/security/trust/message/token
cvs server: Diffing org/apache/ws/security/trust/renew
cvs server: Diffing org/apache/ws/security/trust/request
cvs server: Diffing org/apache/ws/security/trust/validate
cvs server: Diffing org/apache/ws/security/trust/verify
cvs server: Diffing org/apache/ws/security/trust2
cvs server: Diffing org/apache/ws/security/trust2/exception
cvs server: Diffing org/apache/ws/security/trust2/samples
cvs server: Diffing org/apache/ws/security/trust2/serialization
cvs server: Diffing org/apache/ws/security/util
Index: org/apache/ws/security/util/WSSecurityUtil.java
===================================================================
RCS file:
/home/cvspublic/ws-fx/wss4j/src/org/apache/ws/security/util/WSSecurityUtil.java,v
retrieving revision 1.20
diff -u -r1.20 WSSecurityUtil.java
--- org/apache/ws/security/util/WSSecurityUtil.java 9 Aug 2004
17:53:47 -0000 1.20
+++ org/apache/ws/security/util/WSSecurityUtil.java 26 Aug 2004
08:56:41 -0000
@@ -651,7 +651,7 @@
}
/**
- * find the ws-security header block
+ * find the first ws-security header block
* <p/>
*
* @param doc
@@ -660,24 +660,35 @@
* @return
*/
public static Element findWsseSecurityHeaderBlock(WSSConfig
wssConfig, Document doc, Element envelope, boolean doCreate) {
+ return findWsseSecurityHeaderBlock(wssConfig, doc, envelope,
null, doCreate);
+ }
+
+ /**
+ * find a ws-security header block for a given actor
+ * <p/>
+ *
+ * @param doc
+ * @param envelope
+ * @param actor
+ * @param doCreate
+ * @return
+ */
+ public static Element findWsseSecurityHeaderBlock(WSSConfig wssConfig,
+ Document doc,
+ Element envelope,
+ String actor,
+ boolean doCreate) {
SOAPConstants sc = getSOAPConstants(envelope);
+ Element wsseSecurity = getSecurityHeader(wssConfig, doc, actor,
sc);
+ if (wsseSecurity != null) {
+ return wsseSecurity;
+ }
Element header = findChildElement(envelope,
sc.getEnvelopeURI(), sc.getHeaderQName().getLocalPart());
if (header == null) {
if (doCreate) {
header = createElementInSameNamespace(envelope,
sc.getHeaderQName().getLocalPart());
header = prependChildElement(doc, envelope, header, true);
}
- }
- Element wsseSecurity = null;
- if (wssConfig.getProcessNonCompliantMessages()) {
- for (int i = 0; wsseSecurity == null && i <
WSConstants.WSSE_NS_ARRAY.length; ++i) {
- wsseSecurity = findChildElement(header,
WSConstants.WSSE_NS_ARRAY[i], "Security");
- }
- } else {
- wsseSecurity = findChildElement(header,
wssConfig.getWsseNS(), "Security");
- }
- if (wsseSecurity != null) {
- return wsseSecurity;
}
if (doCreate) {
wsseSecurity =
header.getOwnerDocument().createElementNS(wssConfig.getWsseNS(),
"wsse:Security");
Regards,
Yves
Werner Dittmann wrote:
>Yes,
>could be a real bug :-). This "chaining was not very well tested (at least
>not
>with different actors). I need to update my source tree here and have a
>look.
>Appreciate if you can just send a patch or something like that :-).
>
>Regards,
>Werner
>
>----- Original Message -----
>From: "Yves Langisch" <li...@langisch.ch>
>To: <fx...@ws.apache.org>
>Sent: Wednesday, August 25, 2004 6:58 PM
>Subject: [WSS4J] client handler chaining with different actors
>
>
>
>
>>All,
>>
>>On client-side I use a handler chain with following actions:
>>
>>handler1 = Timestamp Signature NoSerialization
>>handler2 = Encrypt
>>
>>For both of them I define a different actor in order to get TWO security
>>headers but the message on the wire always contains only one header
>>(with actor=handler2actor) with all the information (ts, sig, enc) in
>>it. I looked through the source and found the location where this
>>'overwriting' or 'merging' happens: The method insertSecurityHeader in
>>the WSBaseMessage class seems to be 'actor-aware'. But inside of this
>>method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
>>which should add oder supplement a header for a specific actor. But if
>>there is already a security header it always returns this one instead of
>>creating a new one if the actor differs.
>>
>>Am I understanding anything wrong or is this a bug?
>>
>>Regards,
>>Yves
>>
>>PS. I'm using the latest source.
>>
>>
>
>
>
Re: [WSS4J] client handler chaining with different actors
Posted by Werner Dittmann <We...@t-online.de>.
Yes,
could be a real bug :-). This "chaining was not very well tested (at least
not
with different actors). I need to update my source tree here and have a
look.
Appreciate if you can just send a patch or something like that :-).
Regards,
Werner
----- Original Message -----
From: "Yves Langisch" <li...@langisch.ch>
To: <fx...@ws.apache.org>
Sent: Wednesday, August 25, 2004 6:58 PM
Subject: [WSS4J] client handler chaining with different actors
> All,
>
> On client-side I use a handler chain with following actions:
>
> handler1 = Timestamp Signature NoSerialization
> handler2 = Encrypt
>
> For both of them I define a different actor in order to get TWO security
> headers but the message on the wire always contains only one header
> (with actor=handler2actor) with all the information (ts, sig, enc) in
> it. I looked through the source and found the location where this
> 'overwriting' or 'merging' happens: The method insertSecurityHeader in
> the WSBaseMessage class seems to be 'actor-aware'. But inside of this
> method there is a call to WSSecurityUtil.findWsseSecurityHeaderBlock
> which should add oder supplement a header for a specific actor. But if
> there is already a security header it always returns this one instead of
> creating a new one if the actor differs.
>
> Am I understanding anything wrong or is this a bug?
>
> Regards,
> Yves
>
> PS. I'm using the latest source.