subject:"Re\: Websphere 9 and CXF"

RE: Websphere 9 and CXF

2017-10-25 Thread markfuini

Colm,

Thank you.  That makes sense.

I just wonder if I am the only one trying to integrate CXF and Websphere.

Mark

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 25, 2017 5:06 AM
To: markfu...@yahoo.com
Cc: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

The Basic Security Profile mandates that EncryptedData structures must come 
after EncryptedKey structures that reference them:

http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#EncryptedKey_Precedes_EncryptedData

Your best bet is to re-order the header on the receiving side so that the 
EncryptedKey comes before the EncryptedData, if this does not break signature 
verification.

Colm.

On Tue, Oct 24, 2017 at 2:58 PM, <markfu...@yahoo.com> wrote:

> Hi Colm,
>
> The websphere support forum is telling me that the order of the 
> security header should not matter and there is no way to change the 
> order in websphere.
>
> Is there any workaround or facility for class 
> implementation/overriding we can do with CXF to support this?
>
> Mark
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, October 18, 2017 6:57 AM
> To: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
> The problem here is that the EncryptedKey structure, which contains 
> the ReferenceList pointing to the first EncryptedData structure, is 
> below the EncryptedData structure. WSS4J parses the security header in 
> order, and so when it hits the first EncryptedData structure it does 
> not know how to decrypt it. This is a problem with websphere - the 
> ReferenceList or EncryptedKey/ReferenceList must be above the EncryptedData 
> element.
>
> Colm.
>
> On Tue, Oct 17, 2017 at 1:08 PM, <markfu...@yahoo.com.invalid> wrote:
>
> > Hi Colm,
> >
> > Thanks for the help.  Please take a look at this xml generated by 
> > websphere 9 (with the exception of the ... where I replaced information)
> > and let me know if you can think of any workaround.   To me it seems that
> > CXF does not parse the reference list for the EncryptedKey.
> >
> > Here is the error also:
> >
> > http://schemas.xmlsoap.org/soap/envelope/;>
> > 
> > 
> > http://ws.apache.org/wss4j
> > ">ns1:SecurityError
> > A security error was encountered when 
> > verifying the message Caused by: EncryptedKey/EncryptedData does not 
> > contain ds:KeyInfo
> > 
> >  > xmlns="http://cxf.apache.org/fault;>Caused
> > by: org.apache.wss4j.common.ext.WSSecurityException:
> > EncryptedKey/EncryptedData does not contain ds:KeyInfo 
> > #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> > EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> > engine.WSSecurityEngine!processSecurityHeader!WSSecurityEngine.java!
> > 34
> > 0#*#
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!
> handleMessageInternal!
> > WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> > wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*
> > # org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> > WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> > doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> > ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> > 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> > AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> > ServletController!invokeDestination!ServletController.java!234#*#
> > org.apache.cxf.transport.servlet.ServletController!
> > invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> > ServletController!invoke!ServletController.java!160#*#
> > org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> > invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> > AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> > #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> > doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> > HttpServlet!service!HttpServlet.java!648#*#org..
> > apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> > AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> > ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> > 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> > ApplicationFilterChain.java!206#*#org.apache.tomcat.
> > websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> > org.apache.cat

Re: Websphere 9 and CXF

2017-10-25 Thread Colm O hEigeartaigh

The Basic Security Profile mandates that EncryptedData structures must come
after EncryptedKey structures that reference them:

http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#EncryptedKey_Precedes_EncryptedData

Your best bet is to re-order the header on the receiving side so that the
EncryptedKey comes before the EncryptedData, if this does not break
signature verification.

Colm.

On Tue, Oct 24, 2017 at 2:58 PM, <markfu...@yahoo.com> wrote:

> Hi Colm,
>
> The websphere support forum is telling me that the order of the security
> header should not matter and there is no way to change the order in
> websphere.
>
> Is there any workaround or facility for class implementation/overriding we
> can do with CXF to support this?
>
> Mark
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, October 18, 2017 6:57 AM
> To: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
> The problem here is that the EncryptedKey structure, which contains the
> ReferenceList pointing to the first EncryptedData structure, is below the
> EncryptedData structure. WSS4J parses the security header in order, and so
> when it hits the first EncryptedData structure it does not know how to
> decrypt it. This is a problem with websphere - the ReferenceList or
> EncryptedKey/ReferenceList must be above the EncryptedData element.
>
> Colm.
>
> On Tue, Oct 17, 2017 at 1:08 PM, <markfu...@yahoo.com.invalid> wrote:
>
> > Hi Colm,
> >
> > Thanks for the help.  Please take a look at this xml generated by
> > websphere 9 (with the exception of the ... where I replaced information)
> > and let me know if you can think of any workaround.   To me it seems that
> > CXF does not parse the reference list for the EncryptedKey.
> >
> > Here is the error also:
> >
> > http://schemas.xmlsoap.org/soap/envelope/;>
> > 
> > 
> > http://ws.apache.org/wss4j
> > ">ns1:SecurityError
> > A security error was encountered when
> > verifying the message Caused by: EncryptedKey/EncryptedData does not
> > contain ds:KeyInfo
> > 
> > http://cxf.apache.org/fault;>Caused
> > by: org.apache.wss4j.common.ext.WSSecurityException:
> > EncryptedKey/EncryptedData does not contain ds:KeyInfo
> > #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> > EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> > engine.WSSecurityEngine!processSecurityHeader!WSSecurityEngine.java!34
> > 0#*#
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!
> handleMessageInternal!
> > WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> > wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*#
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> > WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> > doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> > ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> > 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> > AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> > ServletController!invokeDestination!ServletController.java!234#*#
> > org.apache.cxf.transport.servlet.ServletController!
> > invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> > ServletController!invoke!ServletController.java!160#*#
> > org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> > invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> > AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> > #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> > doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> > HttpServlet!service!HttpServlet.java!648#*#org..
> > apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> > AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> > ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> > 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> > ApplicationFilterChain.java!206#*#org.apache.tomcat.
> > websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> > org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> > ApplicationFilterChain..java!239#*#org.apache.catalina.
> > core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> > 206#*#org.apache.catalina.core.StandardWrapperValve!
> > invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> > StandardContextValve!invoke

RE: Websphere 9 and CXF

2017-10-24 Thread markfuini

Hi Colm,

The websphere support forum is telling me that the order of the security header 
should not matter and there is no way to change the order in websphere.

Is there any workaround or facility for class implementation/overriding we can 
do with CXF to support this?

Mark

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 6:57 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

The problem here is that the EncryptedKey structure, which contains the 
ReferenceList pointing to the first EncryptedData structure, is below the 
EncryptedData structure. WSS4J parses the security header in order, and so when 
it hits the first EncryptedData structure it does not know how to decrypt it. 
This is a problem with websphere - the ReferenceList or 
EncryptedKey/ReferenceList must be above the EncryptedData element.

Colm.

On Tue, Oct 17, 2017 at 1:08 PM, <markfu...@yahoo.com.invalid> wrote:

> Hi Colm,
>
> Thanks for the help.  Please take a look at this xml generated by 
> websphere 9 (with the exception of the ... where I replaced information)
> and let me know if you can think of any workaround.   To me it seems that
> CXF does not parse the reference list for the EncryptedKey.
>
> Here is the error also:
>
> http://schemas.xmlsoap.org/soap/envelope/;>
> 
> 
> http://ws.apache.org/wss4j
> ">ns1:SecurityError
> A security error was encountered when 
> verifying the message Caused by: EncryptedKey/EncryptedData does not 
> contain ds:KeyInfo
> 
> http://cxf.apache.org/fault;>Caused
> by: org.apache.wss4j.common.ext.WSSecurityException:
> EncryptedKey/EncryptedData does not contain ds:KeyInfo 
> #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> engine.WSSecurityEngine!processSecurityHeader!WSSecurityEngine.java!34
> 0#*# 
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessageInternal!
> WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*#
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> ServletController!invokeDestination!ServletController.java!234#*#
> org.apache.cxf.transport.servlet.ServletController!
> invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> ServletController!invoke!ServletController.java!160#*#
> org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> HttpServlet!service!HttpServlet.java!648#*#org..
> apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> ApplicationFilterChain.java!206#*#org.apache.tomcat.
> websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> ApplicationFilterChain..java!239#*#org.apache.catalina.
> core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> 206#*#org.apache.catalina.core.StandardWrapperValve!
> invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> StandardContextValve!invoke!StandardContextValve.java!106#
> *#org.apache.catalina..authenticator.AuthenticatorBase!invoke!
> AuthenticatorBase.java!502#*#org.apache.catalina.core.
> StandardHostValve!invoke!StandardHostValve.java!141#*#
> org.apache.catalina.valves.ErrorReportValve!invoke!
> ErrorReportValve.java!79#*#org.apache.catalina.valves.
> AbstractAccessLogValve!invoke!AbstractAccessLogValve.java!
> 616#*#org.apache.catalina.core.StandardEngineValve!
> invoke!StandardEngineValve.java!88#*#org.apache.catalina.
> connector.CoyoteAdapter!service!CoyoteAdapter.java!
> 521#*#org.apache.coyote.http11.AbstractHttp11Processor!process!
> AbstractHttp11Processor.java!1096#*#org.apache.coyote.AbstractProtocol
> $ AbstractConnectionHandler!process!AbstractProtocol.java!
> 674#*#org.apache.tomcat.util.net.NioEndpoint$SocketProcessor!doRun!
> NioEndpoint.java

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

This was the last hurdle... 

The api is addAllowedEncryptionMethod for the data not 
addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

The error message was correct that is not a key encryption algo.

With this change, the workaround was fully tested.

Thanks Colm!

-Original Message-
From: markfu...@yahoo.com.INVALID [mailto:markfu...@yahoo.com.INVALID] 
Sent: Wednesday, October 18, 2017 12:30 PM
To: users@cxf.apache.org; cohei...@apache.org
Subject: RE: Websphere 9 and CXF

Thank you.  Agreed.  I  fixed that on the websphere client to use RSA OAEP.  
Additionally had to configure the encryption key reference type in the 
websphere JAX-WS client to REF_ID to make it match what CXF expects.  Otherwise 
I was getting "ENC_KEY_INFO MUST have exactly one child element" error from CXF.

 

  X509GenerateCallbackHandler encryptionCallback1 = new 
X509GenerateCallbackHandler(...);

   SecurityToken encryptingToken= 
wssfactory.newSecurityToken(X509Token.class, encryptionCallback1);

   WSSEncryption encryption = 
wssfactory.newWSSEncryption(encryptingToken);

   encryption.setKeyEncryptionMethod(WSSEncryption.KW_RSA_OAEP);

   encryption.addEncryptPart(WSSEncryption.BODY_CONTENT);

   encryption.addEncryptPartByXPath(sbtimestamp.toString());

   encryption.addEncryptPart(WSSEncryption.SIGNATURE);

   encryption.setTokenReference(X509Token.REF_KEYID);

   

   generationContext.add(encryption); 

   generationContext.process(requestContext

 

The message makes it in and out of CXF from websphere but now the trick is that 
Axis (IBM Websphere) is having hard time decrypting the response...

 

WSSConsumingContext consumerContext = wssfactory.newWSSConsumingContext();

   X509ConsumeCallbackHandler decryptionCallback = new 
X509ConsumeCallbackHandler(…);

   WSSDecryption decryption = 
wssfactory.newWSSDecryption(X509Token.class, decryptionCallback);

   
decryption.addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

   
decryption.addRequiredDecryptPart(WSSDecryption.BODY_CONTENT);

   decryption.addRequiredDecryptPart(WSSDecryption.SIGNATURE);

   consumerContext.add(decryption);

 

This is the error on the websphere client side now…

 

“key encryption method is not valid.”

[10/18/17 12:04:21:575 EDT] 00a7 SystemOut O 
com.ibm.websphere.wssecurity.wssapi.WSSException: CWWSS5364E: The 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc key encryption method is not 
valid.

   at 
com.ibm.websphere.wssecurity.wssapi.WSSException.format(WSSException.java:75)

   at 
com.ibm.ws.wssecurity.wssapi.dec.impl.WSSDecryptionImpl.addAllowedKeyEncryptionMethod(WSSDecryptionImpl.java:210)

   

I do have the outbound configuration to use tripledes-cbc in cxf with spring

 







…





 

   
 

  
 



…

http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>







 

Interoperability not easy.

 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 10:22 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

 

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security policy 
requires RSA OAEP. For example, you might have "Basic128" in your policy, but 
it sounds like the sender is using "Basic128Rsa15".

 

Colm.

 

On Wed, Oct 18, 2017 at 3:17 PM, < <mailto:markfu...@yahoo.com.invalid> 
markfu...@yahoo.com.invalid> wrote:

 

> Hi Colm,

> 

> 

> 

> I am still working on it, it looks like a different issue than the xml

> ordering. Maybe you can see the issue from this information?

> 

> 

> 

> Thanks!

> 

> 

> 

> Mark

> 

> 

> 

> From the logs:

> 

> 

> 

> 2017-10-18 10:09:33 - Found encrypted key element

> 

> 2017-10-18 10:09:38 - Sym Enc Algo:  <http://www.w3.org/2001/04/> 
> http://www.w3.org/2001/04/

> xmlenc#rsa-1_5

> 

> ….

> 

> 2017-10-18 10:09:41 - The Key transport method does not match the 

> requirement

> 

> 

> 

> Stack trace:

> 

> 

> 

> org.apache.cxf.binding.soap.SoapFault: A security error was 

> encountered when verifying the message

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.

> createSoapFault(WSS4JUtils.java:234)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessageInternal(WSS4JInInterceptor.java:340)

> 

> at org.apache.cx

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

Thank you.  Agreed.  I  fixed that on the websphere client to use RSA OAEP.  
Additionally had to configure the encryption key reference type in the 
websphere JAX-WS client to REF_ID to make it match what CXF expects.  Otherwise 
I was getting "ENC_KEY_INFO MUST have exactly one child element" error from CXF.

 

  X509GenerateCallbackHandler encryptionCallback1 = new 
X509GenerateCallbackHandler(...);

   SecurityToken encryptingToken= 
wssfactory.newSecurityToken(X509Token.class, encryptionCallback1);

   WSSEncryption encryption = 
wssfactory.newWSSEncryption(encryptingToken);

   encryption.setKeyEncryptionMethod(WSSEncryption.KW_RSA_OAEP);

   encryption.addEncryptPart(WSSEncryption.BODY_CONTENT);

   encryption.addEncryptPartByXPath(sbtimestamp.toString());

   encryption.addEncryptPart(WSSEncryption.SIGNATURE);

   encryption.setTokenReference(X509Token.REF_KEYID);

   

   generationContext.add(encryption); 

   generationContext.process(requestContext

 

The message makes it in and out of CXF from websphere but now the trick is that 
Axis (IBM Websphere) is having hard time decrypting the response...

 

WSSConsumingContext consumerContext = wssfactory.newWSSConsumingContext();

   X509ConsumeCallbackHandler decryptionCallback = new 
X509ConsumeCallbackHandler(…);

   WSSDecryption decryption = 
wssfactory.newWSSDecryption(X509Token.class, decryptionCallback);

   
decryption.addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

   
decryption.addRequiredDecryptPart(WSSDecryption.BODY_CONTENT);

   decryption.addRequiredDecryptPart(WSSDecryption.SIGNATURE);

   consumerContext.add(decryption);

 

This is the error on the websphere client side now…

 

“key encryption method is not valid.”

[10/18/17 12:04:21:575 EDT] 00a7 SystemOut O 
com.ibm.websphere.wssecurity.wssapi.WSSException: CWWSS5364E: The 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc key encryption method is not 
valid.

   at 
com.ibm.websphere.wssecurity.wssapi.WSSException.format(WSSException.java:75)

   at 
com.ibm.ws.wssecurity.wssapi.dec.impl.WSSDecryptionImpl.addAllowedKeyEncryptionMethod(WSSDecryptionImpl.java:210)

   

I do have the outbound configuration to use tripledes-cbc in cxf with spring

 







…





 

   
 

  
 



…

http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>







 

Interoperability not easy.

 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 10:22 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

 

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security policy 
requires RSA OAEP. For example, you might have "Basic128" in your policy, but 
it sounds like the sender is using "Basic128Rsa15".

 

Colm.

 

On Wed, Oct 18, 2017 at 3:17 PM, < <mailto:markfu...@yahoo.com.invalid> 
markfu...@yahoo.com.invalid> wrote:

 

> Hi Colm,

> 

> 

> 

> I am still working on it, it looks like a different issue than the xml

> ordering. Maybe you can see the issue from this information?

> 

> 

> 

> Thanks!

> 

> 

> 

> Mark

> 

> 

> 

> From the logs:

> 

> 

> 

> 2017-10-18 10:09:33 - Found encrypted key element

> 

> 2017-10-18 10:09:38 - Sym Enc Algo:  <http://www.w3.org/2001/04/> 
> http://www.w3.org/2001/04/

> xmlenc#rsa-1_5

> 

> ….

> 

> 2017-10-18 10:09:41 - The Key transport method does not match the 

> requirement

> 

> 

> 

> Stack trace:

> 

> 

> 

> org.apache.cxf.binding.soap.SoapFault: A security error was 

> encountered when verifying the message

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.

> createSoapFault(WSS4JUtils.java:234)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessageInternal(WSS4JInInterceptor.java:340)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:175)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:86)

> 

> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(

> PhaseInterceptorChain.java:308)

> 

> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(

> ChainInitiationObserver.java:121)

>

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security
policy requires RSA OAEP. For example, you might have "Basic128" in your
policy, but it sounds like the sender is using "Basic128Rsa15".

Colm.

On Wed, Oct 18, 2017 at 3:17 PM, <markfu...@yahoo.com.invalid> wrote:

> Hi Colm,
>
>
>
> I am still working on it, it looks like a different issue than the xml
> ordering. Maybe you can see the issue from this information?
>
>
>
> Thanks!
>
>
>
> Mark
>
>
>
> From the logs:
>
>
>
> 2017-10-18 10:09:33 - Found encrypted key element
>
> 2017-10-18 10:09:38 - Sym Enc Algo: http://www.w3.org/2001/04/
> xmlenc#rsa-1_5
>
> ….
>
> 2017-10-18 10:09:41 - The Key transport method does not match the
> requirement
>
>
>
> Stack trace:
>
>
>
> org.apache.cxf.binding.soap.SoapFault: A security error was encountered
> when verifying the message
>
> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.
> createSoapFault(WSS4JUtils.java:234)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessageInternal(WSS4JInInterceptor.java:340)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessage(WSS4JInInterceptor.java:175)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessage(WSS4JInInterceptor.java:86)
>
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:308)
>
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
>
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> AbstractHTTPDestination.java:267)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invokeDestination(ServletController.java:234)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:208)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:160)
>
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.
> invoke(CXFNonSpringServlet.java:191)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> handleRequest(AbstractHTTPServlet.java:301)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> doPost(AbstractHTTPServlet.java:220)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> service(AbstractHTTPServlet.java:276)
>
> at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:291)
>
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
>
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(
> WsFilter.java:52)
>
>
>
>
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, October 18, 2017 9:44 AM
> To: markfu...@yahoo.com
> Cc: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
>
>
> What was the error you saw when you moved the EncryptedKey Element above
> the EncryptedData Element? What is actually stored inside the first
> EncryptedData Element?
>
> Colm.
>
>
>
> On Wed, Oct 18, 2017 at 1:04 PM, Mark Fuini <markfu...@yahoo.com  markfu...@yahoo.com> > wrote:
>
> Thank you so much for getting back to me.  This is an ongoing daily issue
> for us.
>
>
>
> The conclusion you came to was my analysis also.
>
>
>
> But I not sure the actual xml ordering is part of the spec.  So their xml
> may be valid.  But that means web service which use event driven xml
> parsing are at a disadvantage because the security node  would have to be
> completely parsed before assuming the key is not there.
>
>
>
> Regardless IBM is not going to change their security engine just for me.
>
>
>
> Any ideas for work around?
>
>
>
> One idea:
>
> I tried a message change interceptor in cxf on the server side and
> reordered the encrypted key to be first element in the security node.  Is
> this a valid way to resolve it on server side?  It did not work completely.
>
>
>
> The missing keyInfo message went away but then I received a security
> header error.  Can you please try that with the sample xml or I can resend
> it?
>
> Any other suggestions?
>
>
> Thanks again.
>
> On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh
>
> <cohei...@apache.org <mailto:cohei...@apache.org> > wrote:
>
> The problem here is that the EncryptedKey structure, which contai

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

Hi Colm,

I am still working on it, it looks like a different issue than the xml 
ordering. Maybe you can see the issue from this information?

Thanks!

Mark

>From the logs:

2017-10-18 10:09:33 - Found encrypted key element

2017-10-18 10:09:38 - Sym Enc Algo: http://www.w3.org/2001/04/xmlenc#rsa-1_5

….

2017-10-18 10:09:41 - The Key transport method does not match the requirement

Stack trace:

org.apache.cxf.binding.soap.SoapFault: A security error was encountered when 
verifying the message

at 
org.apache.cxf.ws.security.wss4j.WSS4JUtils.createSoapFault(WSS4JUtils.java:234)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:340)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:175)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:86)

at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)

at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)

at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)

at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)

at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)

at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:191)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 9:44 AM
To: markfu...@yahoo.com
Cc: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

What was the error you saw when you moved the EncryptedKey Element above the 
EncryptedData Element? What is actually stored inside the first EncryptedData 
Element?

Colm.

On Wed, Oct 18, 2017 at 1:04 PM, Mark Fuini <markfu...@yahoo.com 
<mailto:markfu...@yahoo.com> > wrote:

Thank you so much for getting back to me.  This is an ongoing daily issue for 
us.

The conclusion you came to was my analysis also. 

But I not sure the actual xml ordering is part of the spec.  So their xml may 
be valid.  But that means web service which use event driven xml parsing are at 
a disadvantage because the security node  would have to be completely parsed 
before assuming the key is not there.

Regardless IBM is not going to change their security engine just for me.

Any ideas for work around?

One idea:

I tried a message change interceptor in cxf on the server side and reordered 
the encrypted key to be first element in the security node.  Is this a valid 
way to resolve it on server side?  It did not work completely.

The missing keyInfo message went away but then I received a security header 
error.  Can you please try that with the sample xml or I can resend it?

Any other suggestions?

Thanks again.

On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh

<cohei...@apache.org <mailto:cohei...@apache.org> > wrote:

The problem here is that the EncryptedKey structure, which contains the
ReferenceList pointing to the first EncryptedData structure, is below the
EncryptedData structure. WSS4J parses the security header in order, and so
when it hits the first EncryptedData structure it does not know how to
decrypt it. This is a problem with websphere - the ReferenceList or
EncryptedKey/ReferenceList must be above the EncryptedData element.

Colm.

On Tue, Oct 17, 2017 at 1:08 PM, <markfu...@yahoo.com.invalid 
<mailto:markfu...@yahoo.com.invalid> > wrote:

> Hi Colm,
>
> Thanks for the help.  Please take a look at this xml generated by
> websphere 9 (with the exception of the ... where I replaced information)
> and let me know if you can think of any workaround.  To me it seems that
> CXF does not parse the reference list for the EncryptedKey.
>
> Here is the error also:
>
> http://schemas.xmlsoap.org/soap/envelope/;>
>
>
>http://ws.apache.org/wss4j
> ">ns1:SecurityError
>

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

t; > org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> > ApplicationFilterChain..java!239#*#org.apache.catalina.
> > core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> > 206#*#org.apache.catalina.core.StandardWrapperValve!
> > invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> > StandardContextValve!invoke!StandardContextValve.java!106#
> > *#org.apache.catalina..authenticator.AuthenticatorBase!invoke!
> > AuthenticatorBase.java!502#*#org.apache.catalina.core.
> > StandardHostValve!invoke!StandardHostValve.java!141#*#
> > org.apache.catalina.valves.ErrorReportValve!invoke!
> > ErrorReportValve.java!79#*#org.apache.catalina.valves.
> > AbstractAccessLogValve!invoke!AbstractAccessLogValve.java!
> > 616#*#org.apache.catalina.core.StandardEngineValve!
> > invoke!StandardEngineValve.java!88#*#org.apache.catalina.
> > connector.CoyoteAdapter!service!CoyoteAdapter.java!
> > 521#*#org.apache.coyote.http11.AbstractHttp11Processor!process!
> > AbstractHttp11Processor.java!1096#*#org.apache.coyote.AbstractProtocol$
> > AbstractConnectionHandler!process!AbstractProtocol.java!
> > 674#*#org.apache.tomcat.util.net.NioEndpoint$SocketProcessor!doRun!
> > NioEndpoint.java!1500#*#org.apache.tomcat.util.net.
> > NioEndpoint$SocketProcessor!run!NioEndpoint.java!1456#*#
> > java.util.concurrent.ThreadPoolExecutor!runWorker!
> > ThreadPoolExecutor.java!1149#*#java.util.concurrent.
> > ThreadPoolExecutor$Worker!run!ThreadPoolExecutor.java!624#*#
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable!run!
> > TaskThread.java!61#*#java.lang.Thread!run!Thread.java!
> 748#*#
> >
> >
> >
> >
> > Mark
> >
> > http://schemas.
> xmlsoap.org/soap/envelope/
> > ">
> >
> >http://docs.oasis-
> > open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> > soapenv:mustUnderstand="1">
> >http://www.w3.org/
> > 2001/04/xmlenc#" Id="wssecurity_encryption_id_24" Type="
> > http://www.w3.org/2001/04/xmlenc#Element;>
> >http://www.w3.org/
> > 2001/04/xmlenc#aes128-cbc">
> >
> >...
> >
> >
> >http://docs.oasis-
> > open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> > wsu:Id="x509bst_22" EncodingType="http://docs.
> oasis-open.org/wss/2004/01/
> > oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="
> > http://docs.oasis-open.org/wss/2004/01/oasis-
> > 200401-wss-x509-token-profile-1.0#X509v3">...
> >http://docs.oasis-
> > open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> > wsu:Id="unt_20">
> >...
> >http://docs.oasis-open.
> > org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> > ">...
> >
> >http://www.w3.org/
> 2001/04/xmlenc#
> > ">
> >http://www.w3.org/
> > 2001/04/xmlenc#rsa-1_5">
> >http://www.w3.org/2000/09/xmldsig#
> ">
> >
> >
> >
> >... X509IssuerName>
> >... > X509SerialNumber>
> >
> >
> >
> >
> >
> >    ...
> >
> >
> >
> >
> >
> >
> >
> >http://www.w3.org/
> > 2001/04/xmlenc#" Id="wssecurity_encryption_id_25" Type="
> > http://www.w3.org/2001/04/xmlenc#Element;>
> >http://www.w3.org/
> > 2001/04/xmlenc#aes128-cbc">
> >
> >...
> >
> >
> >
> >
> >http://docs.oasis-
> open.org/wss/2004/01/oasis-
> > 200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="wssecurity_signature_
> > id_21">
> >http://www.w3.org/2001/04/xmlenc#;
> > Id="wssecurity_encryption_id_26" Type="http://www.w3.org/2001/
> > 04/xmlenc#Content">
> >http://www.w3.org/
> > 2001/04/xm

Re: Websphere 9 and CXF

2017-10-18 Thread Mark Fuini

t; AbstractAccessLogValve!invoke!AbstractAccessLogValve.java!
> 616#*#org.apache.catalina.core.StandardEngineValve!
> invoke!StandardEngineValve.java!88#*#org.apache.catalina.
> connector.CoyoteAdapter!service!CoyoteAdapter.java!
> 521#*#org.apache.coyote.http11.AbstractHttp11Processor!process!
> AbstractHttp11Processor.java!1096#*#org.apache.coyote.AbstractProtocol$
> AbstractConnectionHandler!process!AbstractProtocol.java!
> 674#*#org.apache.tomcat.util.net.NioEndpoint$SocketProcessor!doRun!
> NioEndpoint.java!1500#*#org.apache.tomcat.util.net.
> NioEndpoint$SocketProcessor!run!NioEndpoint.java!1456#*#
> java.util.concurrent.ThreadPoolExecutor!runWorker!
> ThreadPoolExecutor.java!1149#*#java.util.concurrent.
> ThreadPoolExecutor$Worker!run!ThreadPoolExecutor.java!624#*#
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable!run!
> TaskThread.java!61#*#java.lang.Thread!run!Thread.java!748#*#
>            
>        
>    
>
> Mark
>
> http://schemas.xmlsoap.org/soap/envelope/
> ">
>    
>        http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> soapenv:mustUnderstand="1">
>            http://www.w3.org/
> 2001/04/xmlenc#" Id="wssecurity_encryption_id_24" Type="
> http://www.w3.org/2001/04/xmlenc#Element;>
>                http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
>                
>                    ...
>                
>            
>            http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="x509bst_22" EncodingType="http://docs.oasis-open.org/wss/2004/01/
> oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-x509-token-profile-1.0#X509v3">...
>            http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="unt_20">
>                ...
>                http://docs.oasis-open.
> org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">...
>            
>            http://www.w3.org/2001/04/xmlenc#
> ">
>                http://www.w3.org/
> 2001/04/xmlenc#rsa-1_5">
>                http://www.w3.org/2000/09/xmldsig#;>
>                    
>                        
>                            
>                                ...
>                                ... X509SerialNumber>
>                            
>                        
>                    
>                
>                
>                    ...
>                
>                
>                    
>                    
>                    
>                
>            
>            http://www.w3.org/
> 2001/04/xmlenc#" Id="wssecurity_encryption_id_25" Type="
> http://www.w3.org/2001/04/xmlenc#Element;>
>                http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
>                
>                    ...
>                
>            
>        
>    
>    http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="wssecurity_signature_
> id_21">
>        http://www.w3.org/2001/04/xmlenc#;
> Id="wssecurity_encryption_id_26" Type="http://www.w3.org/2001/
> 04/xmlenc#Content">
>            http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
>            
>                ...
>            
>        
>    
> 
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, October 17, 2017 5:31 AM
> To: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
> Can you give an example of the websphere request that CXF does not parse
> correctly?
>
> Colm.
>
> On Mon, Oct 16, 2017 at 10:14 PM, <markfu...@yahoo.com.invalid> wrote:
>
> > Hi,
> >
> >
> >
> > I am trying to get the websphere 9 container's built in security
> > engine to programmatically generate a soap JAX-WS secure client
> > request to a CXF web service.
> >
> >
> >
> > The problem is that websphere's engine is not repeating the
> > EncryptedKey under each EncryptedData element and is using a reference
> > list to minimize how many times this information is in the message.
> >
> >
> >
> > However CXF 3.2.0 and 3.1.7 do not seem to parse the EncryptedKey Info
> > from the reference list and replace them.  So it reports the
> > EncryptedData has no keyInfo element.
> >
> >
> >
> > It seems to be an optimize on IBM's end that Apache CXF has not
> > implemented.
> >
> >
> >
> > Let me know if anyone has had this problem.
> >
> >
> >
> > Thanks in advance,
> >
> >
> >
> > Mark
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>


-- 
Colm O hEigeartaigh

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

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

t; http://schemas.xmlsoap.org/soap/envelope/
> ">
> 
> http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> soapenv:mustUnderstand="1">
> http://www.w3.org/
> 2001/04/xmlenc#" Id="wssecurity_encryption_id_24" Type="
> http://www.w3.org/2001/04/xmlenc#Element;>
> http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
> 
> ...
> 
> 
> http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="x509bst_22" EncodingType="http://docs.oasis-open.org/wss/2004/01/
> oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-x509-token-profile-1.0#X509v3">...
> http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="unt_20">
> ...
> http://docs.oasis-open.
> org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">...
> 
> http://www.w3.org/2001/04/xmlenc#
> ">
> http://www.w3.org/
> 2001/04/xmlenc#rsa-1_5">
> http://www.w3.org/2000/09/xmldsig#;>
> 
> 
> 
> ...
> ... X509SerialNumber>
> 
> 
> 
> 
> 
> ...
> 
> 
> 
> 
> 
> 
> 
> http://www.w3.org/
> 2001/04/xmlenc#" Id="wssecurity_encryption_id_25" Type="
> http://www.w3.org/2001/04/xmlenc#Element;>
> http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
> 
> ...
>         
>     
> 
> 
> http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="wssecurity_signature_
> id_21">
> http://www.w3.org/2001/04/xmlenc#;
> Id="wssecurity_encryption_id_26" Type="http://www.w3.org/2001/
> 04/xmlenc#Content">
> http://www.w3.org/
> 2001/04/xmlenc#aes128-cbc">
> 
> ...
> 
> 
> 
> 
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, October 17, 2017 5:31 AM
> To: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
> Can you give an example of the websphere request that CXF does not parse
> correctly?
>
> Colm.
>
> On Mon, Oct 16, 2017 at 10:14 PM, <markfu...@yahoo.com.invalid> wrote:
>
> > Hi,
> >
> >
> >
> > I am trying to get the websphere 9 container's built in security
> > engine to programmatically generate a soap JAX-WS secure client
> > request to a CXF web service.
> >
> >
> >
> > The problem is that websphere's engine is not repeating the
> > EncryptedKey under each EncryptedData element and is using a reference
> > list to minimize how many times this information is in the message.
> >
> >
> >
> > However CXF 3.2.0 and 3.1.7 do not seem to parse the EncryptedKey Info
> > from the reference list and replace them.  So it reports the
> > EncryptedData has no keyInfo element.
> >
> >
> >
> > It seems to be an optimize on IBM's end that Apache CXF has not
> > implemented.
> >
> >
> >
> > Let me know if anyone has had this problem.
> >
> >
> >
> > Thanks in advance,
> >
> >
> >
> > Mark
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>


-- 
Colm O hEigeartaigh

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

RE: Websphere 9 and CXF

2017-10-17 Thread markfuini

.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText;>...

http://www.w3.org/2001/04/xmlenc#;>
http://www.w3.org/2001/04/xmlenc#rsa-1_5;>
http://www.w3.org/2000/09/xmldsig#;>



...
...





...







http://www.w3.org/2001/04/xmlenc#; 
Id="wssecurity_encryption_id_25" 
Type="http://www.w3.org/2001/04/xmlenc#Element;>
http://www.w3.org/2001/04/xmlenc#aes128-cbc;>

...




http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 wsu:Id="wssecurity_signature_id_21">
http://www.w3.org/2001/04/xmlenc#; 
Id="wssecurity_encryption_id_26" 
Type="http://www.w3.org/2001/04/xmlenc#Content;>
http://www.w3.org/2001/04/xmlenc#aes128-cbc;>

...





-Original Message-----
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, October 17, 2017 5:31 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

Can you give an example of the websphere request that CXF does not parse 
correctly?

Colm.

On Mon, Oct 16, 2017 at 10:14 PM, <markfu...@yahoo.com.invalid> wrote:

> Hi,
>
>
>
> I am trying to get the websphere 9 container's built in security 
> engine to programmatically generate a soap JAX-WS secure client 
> request to a CXF web service.
>
>
>
> The problem is that websphere's engine is not repeating the 
> EncryptedKey under each EncryptedData element and is using a reference 
> list to minimize how many times this information is in the message.
>
>
>
> However CXF 3.2.0 and 3.1.7 do not seem to parse the EncryptedKey Info 
> from the reference list and replace them.  So it reports the 
> EncryptedData has no keyInfo element.
>
>
>
> It seems to be an optimize on IBM's end that Apache CXF has not 
> implemented.
>
>
>
> Let me know if anyone has had this problem.
>
>
>
> Thanks in advance,
>
>
>
> Mark
>
>


--
Colm O hEigeartaigh

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

Re: Websphere 9 and CXF

2017-10-17 Thread Colm O hEigeartaigh

Can you give an example of the websphere request that CXF does not parse
correctly?

Colm.

On Mon, Oct 16, 2017 at 10:14 PM,  wrote:

> Hi,
>
>
>
> I am trying to get the websphere 9 container's built in security engine to
> programmatically generate a soap JAX-WS secure client request to a CXF web
> service.
>
>
>
> The problem is that websphere's engine is not repeating the EncryptedKey
> under each EncryptedData element and is using a reference list to minimize
> how many times this information is in the message.
>
>
>
> However CXF 3.2.0 and 3.1.7 do not seem to parse the EncryptedKey Info from
> the reference list and replace them.  So it reports the EncryptedData has
> no
> keyInfo element.
>
>
>
> It seems to be an optimize on IBM's end that Apache CXF has not
> implemented.
>
>
>
> Let me know if anyone has had this problem.
>
>
>
> Thanks in advance,
>
>
>
> Mark
>
>


-- 
Colm O hEigeartaigh

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

RE: Websphere 9 and CXF

Re: Websphere 9 and CXF

RE: Websphere 9 and CXF

RE: Websphere 9 and CXF

RE: Websphere 9 and CXF

Re: Websphere 9 and CXF

RE: Websphere 9 and CXF

Re: Websphere 9 and CXF

Re: Websphere 9 and CXF

Re: Websphere 9 and CXF

RE: Websphere 9 and CXF

Re: Websphere 9 and CXF

12 matches

Site Navigation

Mail list logo

Footer information