Re: Mitigations for POODLE vulnerability

What would you recommend as a suggested best approach to address the issue? For example, do you think the best approach is to write out own code to create a Jetty engine that excludes SSLv3 and registers it with the CXF bus? Is there an easier approach? Thanks, D -- View this message in cont

Mitigations for POODLE vulnerability

A security vulnerability has been discovered with SSLv3 protocol. It is also called POODLE attack. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 We would like to mitigate against this by disabling SSL for our various jetty engines. However, I can't seem to find a way to exclude this

Re: CXF is not handling SOAP fault

Dan, you are the MAN. Of course, you are absolutely right about the WSO2 WSDL being total rubbish. I filed a support ticket for that. However, the transformInInterceptor proved to be a viable work around. I don't particularly like it but I don't exactly have an option at this point. Hopefully, WS

Re: CXF is not handling SOAP fault

Is there a way to have CXF ignore the namespace differences? -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-is-not-handling-SOAP-fault-tp5737422p5737740.html Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF is not handling SOAP fault

It seems like the cxf-codegen-plugin has some effect on the expected namespace for the SOAP message. Is there a way to tweak the codegen plugin so that it either ignores the namespace or I can set it to the namespace it will get back? Here's what I'm doing right now in the codegen plugin

Re: CXF is not handling SOAP fault

Hi Dan, I poked around a bit and found that the port type was being set in two separate places in the code. I fixed that and now it looks like I'm getting an entirely different error. It seems that this time we are definitely sending and receiving SOAP. However there seems to be some problem marsh

Re: CXF is not handling SOAP fault

Turns out the person who originally wrote the code was overriding the endpoint address. Like so: BindingProvider bp = (BindingProvider) this.entitlementServicePort; bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, this.entitlementServiceUrl);

Re: CXF is not handling SOAP fault

Here is the full output when using the SOAP11 endpoint. [ main] ReflectionServiceFactoryBean INFO Creating Service {http://entitlement.identity.carbon.wso2.org}EntitlementService from WSDL: file:/Users/212314537/Development/workspaces/dsp/dsp/dsp-gateway/authorization/w

Re: CXF is not handling SOAP fault

Same results when using: private EntitlementServicePortType entitlementServicePort = this.entitlementService .getEntitlementServiceHttpsSoap11Endpoint(); Maybe that helps narrow the prob

Re: CXF is not handling SOAP fault

Hi Aki, I tried switching to: private EntitlementServicePortType entitlementServicePort = this.entitlementService .getEntitlementServiceHttpsSoap12Endpoint(); and I see the exact same results. In this ca

Re: CXF is not handling SOAP fault

Hi Dan, I wanted to add some more information that my help to my previous. The code uses reflection to invoke the method provided by the CXF port. Here are some snippets: String requestStr = Object[] parameters = { requestStr }; Class[] parameterTypes = { String.class }; String operati

Re: CXF is not handling SOAP fault

Hi Dan, Thanks so much for responding. I am generating the client using the cxf-codgen-plugin for Maven (version 2.7.3). I am getting the port using the following code: private EntitlementServicePortType entitlementServicePort = this.entitlementService

Re: CXF is not handling SOAP fault

Hi Aki, Thanks for the response. Hopefully, this sheds some light on the situation: [ main] ReflectionServiceFactoryBean INFO Creating Service {http://entitlement.identity.carbon.wso2.org}EntitlementService from WSDL: file:/Users/212314537/Development/workspaces/dsp/ds

CXF is not handling SOAP fault

Using the cxf-codegen-plugin (version 2.7.3), I have generated client ports/proxies for a SOAP service. When the SOAP service returns a successful response everything works fine. However, when the SOAP service returns a fault, it seems that CXF is not able to convert the SOAP fault in the correct a

Re: Question regarding StaticSTSProperties

Thanks Dan, I'll do that. -- View this message in context: http://cxf.547215.n5.nabble.com/Question-regarding-StaticSTSProperties-tp5728499p5728518.html Sent from the cxf-user mailing list archive at Nabble.com.

Question regarding StaticSTSProperties

While experimenting with the STS code I discovered that configureProperties() method of the StaticSTSProperties class requires a CXF message context in order to execute successfully. This seems a little strange to me because as far as I understand the properties are set once and there is nothing

Re: Problems with http conduit declared in OSGi spring configuration

Dan, as you suggested, I put various break points in org.apache.cxf.configuration.spring.ConfigurerImpl. What I discovered is that if I put my cxf HTTPConduit definitions in the main spring configuration, when configureBean() is called the application context is in a different bundle than expected.

Re: Problems with http conduit declared in OSGi spring configuration

I'm using a combination of cxf feature files. The dosgi stuff is loaded separately from those. I'll try debugging with the break points Dan suggested first. Creating a simple example is something I'm less enthusiastic about doing because its both time consuming and there are no guarantees I could r

Re: Problems with http conduit declared in OSGi spring configuration

I'm using Karaf, The run levels for CXF are: [ 146] [Active ] [Created ] [ ] [ 40] Apache CXF API (2.7.3) [ 147] [Active ] [Created ] [ ] [ 40] Apache CXF Runtime Core (2.7.3) [ 148] [Active ] [] [ ] [ 40] Apache CXF Runtime Management (2.7.3

Re: Problems with http conduit declared in OSGi spring configuration

There's something about the logic of that explanation that does not make sense to me (though I'll readily admit that may very well be due to my ignorance on the matter). You say that the bundle might be picking up the wrong bus. But why would the bundle pick up the right bus on a restart? Why woul

Re: Problems with http conduit declared in OSGi spring configuration

Yes, I actually came to that conclusion as well as I mentioned in the two previous replies: "The "depends-on" attribute would have to be in the bean with the client code that requires the http conduit not the other way around." I also mentioned in my previous two messages that even if I put a "de

Re: Problems with http conduit declared in OSGi spring configuration

You are right that the SpringBus bean was not necessary. However, it does not solve the original problem. My understanding of the SpringBus was that if a bus already existed, it would not create a new one but rather provide you with a way to configure the existing bus. I see now that it is not even

Re: Problems with http conduit declared in OSGi spring configuration

Thanks for your response Daniel. However, I'm not sure whether what you are suggesting is to solve the original problem or if you pointing out another issue with the configuration? -- View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-sprin

Re: Problems with http conduit declared in OSGi spring configuration

I did try the "depends-on" and it did not work. I posted this earlier but am copy/pasting it here again: = Unfortunately, this does not work. First, I misspoke in my previous post. The "depends-on" attribute would have to be in the bean with the client code that requires th

Re: Problems with http conduit declared in OSGi spring configuration

Hi Sergey, Just wondering if you had any thoughts on the new information I posted? Thanks. -- View this message in context: http://cxf.547215.n5.nabble.com/Problems-with-http-conduit-declared-in-OSGi-spring-configuration-tp5727009p5727282.html Sent from the cxf-user mailing list archive at

Re: Problems with http conduit declared in OSGi spring configuration

Unfortunately, this does not work. First, I misspoke in my previous post. The "depends-on" attribute would have to be in the bean with the client code that requires the http conduit not the other way around. However, even if I do that using a configuration like the one below:

Re: Problems with http conduit declared in OSGi spring configuration

Apparently, I spoke to soon. If I load the cxf configuration for my OSGi bundle in the following manner: String[] configs = new String[] { "classpath:META-INF/spring/cxf-context.xml" //$NON-NLS-1$ }; OsgiBundleXmlApplicationContex

Problems with http conduit declared in OSGi spring configuration

I've noticed some less than ideal behavior when I declare an HTTP conduit in the spring configuration of an OSGi bundle. Let's say I have configured an HTTP conduit in META-INF/spring/module-context.xml: http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; /> htt

Re: SOAP body is always empty when making a call using invoke

Just an update to this: I was able to get a response from the WSO2 STS by essentially injecting MessagePartInfo object instances into the BindingOperationInfo instance created from the WSDL. Still this seems like a hack to me and I'm sure there must be an easier way to do this and I'm simply miss

SOAP body is always empty when making a call using invoke

I've been struggling for the past day with an issue where when I call client.invoke() my soap envelope and headers look good but the body is empty even though I am passing a parameter. I've stepped through the code like crazy and I can see where opportunities to write the body are missed. For exam

Re: DefaultSecurityTokenServiceProvider does not use CXF UsernameTokenValidator

Thanks for pointing that out Colm. Once I started debugging from that entry point I realized there was a subtle bug in my validator. Everything works now. Once again many thanks for the help. I truly appreciate it. -- View this message in context: http://cxf.547215.n5.nabble.com/DefaultSecurity

Re: Question on org.apache.cxf.rs.provider

I can confirm that String[] works. I thought it didn't at first, but then I realized that toArray() produces an Object[] even when the type is ArrayList (stupid Java). While using String[] works, it's still not ideal for us because we also need the ability to pass an object as well. Is there a JIR

Re: Question on org.apache.cxf.rs.provider

Thank for pointing out that class. That was very helpful in debugging. Unfortunately, the behavior is still the same only more baffling than before! Here's what I'm doing: List providers = new ArrayList(); providers.add(new org.apache.cxf.rs.security.saml.SamlHeaderInHandler()); providers.add(new

Re: DefaultSecurityTokenServiceProvider does not use CXF UsernameTokenValidator

Well I must be doing something wrong but I don't know what it is. Here is what I have: https://localhost:${port}/SecurityTokenService/Transport"; wsdlLocation="wsdl/ws-trust-1.4-service.wsdl" xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"; serviceName="ns

Question on org.apache.cxf.rs.provider

According to the documentation located at https://cxf.apache.org/distributed-osgi-reference.html, there are three ways one can specify org.apache.cxf.rs.provider: as a string, string[], or list. However, I am seeing different behavior when I use one vs. the other. For example: I can specify the pr

DefaultSecurityTokenServiceProvider does not use CXF UsernameTokenValidator

I'm copying/pasting this from a blog posting where I first reported this issue. You can find the original problem description and interaction with the blogger here: http://coheigea.blogspot.com/2011/11/apache-cxf-sts-documentation-part-viii_10.html?showComment=1365017694507#c377579003061518755 He

Re: Code only STSClient

I believe I have found the problem. Glen's suggestion of using a debugger to figure out the problem turned out to be a very good one. I put breakpoints in the following places: HTTPConduit constructor SpringBus constructor SpringBus setApplicationContext() method Start of my client code End of my

Re: Code only STSClient

Hi Glen, I agree with you that debugging may be the only option left at this point. I also agree that it would be a great learning opportunity to debug Karaf. In fact, I think it's a great idea and I am an advocate of that approach. The last time I ran into a similar unexplained problem I had to d

RE: Code only STSClient

I have more information to add to this bizarre problem. The sheer act of injecting "cxf" as a SpringBus property causes SpringBusFactory.getThreadDefaultBus() to return a bus that works. Let me clarify: I am injecting the bean with name="cxf" (see bean definition below). The field that the setter

RE: Code only STSClient

Just to re-iterate. The nature of the error is clear to me (not my first rodeo with SSL/TLS :) What's not clear is why cxf is not using the trust store that I set up in the configuration. It works just fine when I inject the bus as a string property but not when using getDefaultBus() or getThreadD

Re: Code only STSClient

Yes, of course but the configured is setup with the right trust store. The question is: why is it not picking up the trust store configuration in the ? -- View this message in context: http://cxf.547215.n5.nabble.com/Code-only-STSClient-tp5724575p5724900.html Sent from the cxf-user mailing lis

RE: Code only STSClient

Andrei, Unfortunately, getDefaultBus() and getDefaultSpringBus() are not returning a bus that works. On the other hand, injecting the bus into a class property does work. Here is my spring configuration: http://docs.oasis-open.org/ws-sx/ws-trust/20051

RE: Code only STSClient

Just to clarify, I DO want to use the CXF STSClient. I have no intention of re-inventing the wheel. Actually, I am mostly following the code in the CXF system tests for my own functional tests. The problem is that most of those tests initialize the CXF like this: SpringBus bus = (SpringBus) bf.cre

RE: Code only STSClient

The short answer is that there is no concrete use case yet (you can thank agile development for that). The longer answer is that I was tasked with building a WS-Trust 1.4 compliant STS to issue SAML assertions that relying parties external to the OSGI container hosting the STS might consume. These

Re: Code only STSClient

Thanks for the response. The short answer is that I didn't really set it to false. I just copied it like that from the CXF system tests. I'll look at the links you suggested. Perhaps the solution is as simple as setting that flag to true. Have a great weekend. -- View this message in context: h

Re: Code only STSClient

I took a look at the samples and while they are very useful they don't really address my particular problem. I was able to overcome that problem in one way but that solution leads to more questions. Basically, I can make the solution work by making my class ApplicationContextAware. In my bundles mo

Re: Code only STSClient

Thanks for samples, I will take a look at them. FWIW I have no problem hosting web services in Karaf using CXF. I have created several web services both SOAP and REST versions using Spring. Where I am stuck is creating and using CXF clients in an OSGI bundle. -- View this message in context: ht

Code only STSClient

I've spent a day trying to figure out how to build a code only STSClient. I would like to do the analogue of the following in code only: http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; createdFromAPI="false" username="a

SamlHeaderInHandler exception

Strangely (or maybe not strangely) the SamlHeaderInHandler that is working perfectly when hosted on an OSGI container on my mac running OS X Mountain Lion is throwing an exception when running in windows. Everything is identical except, of course, the JVM. Furthermore the exception is a bit obtuse.

Re: SAML metadata

I'll be sure to share whatever I learn if we are tasked to implement this kind of functionality. So far our product owners are saying this is not strictly necessary but that could change. Regarding OAuth, the last time I read the specification it was essentially token agnostic. Other than the fact

RE: SAML metadata

OK I'll explain from the start. I apologize for the length of what will follow but at least it will provide a solid foundation. This specific use case I am concerned with is trying to provide a SAML based authentication and authorization layer using SAML assertions. A popular solution for providin

Re: SAML metadata

FYI - the specification is here: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf If you want to see one implementation of this take a look at ForgeRock's OpenAM. In a way this is similar to the FederationMetadata.xml file you exchange to establish trust when using WS-Feder

Re: SAML metadata

This is not something that happens every request. It happens when you make a decision to trust an external identity provider so it is a relatively rare event. The key word here is "external". For example, suppose you decide to trust a third party STS to issue SAML tokens that you can use for web se

RE: SAML metadata

No. I am talking about metadata used to exchange out-of-band information about what asserting party a relying party should trust and what relying party an asserting provider should issue tokens for. Currently, in CXF you establish trust between the relying party and the asserting provider (i.e. se

Re: SAML metadata

Hi Colm, Thanks for the prompt response. Do you think this is the kind of feature that makes sense for CXF to provide? Are there any plans to support it? In the meanwhile, my thinking is that anyone who wants this feature can build it by using OpenSAML to parse the metadata and then write code to

SAML metadata

I'm wondering if CXF has supports setting up the trust relationship between an STS and SP using SAML metadata. Thus far, the examples in the systests and sample code seem to imply that trust between the STS and SP is established by exchange certificates and placing them in trust keystores. I have n

Re: STSClient requestSecurityToken exception.

Some of the imports in my Maven plugin was not specifying a path. Thus, when I ran my TestNG test with the client STS code it was loading 2.5.2 instead of 2.7.2 and as the exception message clearly indicates the method it was looking for was not implemented in the 2.5.2 version of the class. It's r

STSClient requestSecurityToken exception.

I'm trying to replicate one of the CXF system tests unsuccessfully. The test in question is located in the cxf-services-sts-systests-basic maven project in the IssueUnit class it is the testBearerSVSaml2 method. The twist is that I'm hosting the STS server in an OSGI container. The STS seems to s

Re: SAML authentication in OSGI continued

It was just a general comment about developing with open source tools and frameworks. Web services and SAML are not new to me but my background is in developing in .NET for Microsoft platforms and the experience is smoother for lack of a better word. I am not suggesting one way is better than the o

Re: SAML authentication in OSGI continued

The development experience wasn't exactly plug-n-play... but it works and there seems to be a lot of power under the hood once you start to understand the framework. My gut reaction to this technology is that the level of knowledge and skill necessary to start using it is very high. I am however re

Re: SAML authentication in OSGI continued

Thanks Sergey, I can confirm that both those methods worked. -- View this message in context: http://cxf.547215.n5.nabble.com/SAML-authentication-in-OSGI-continued-tp5723161p5723194.html Sent from the cxf-user mailing list archive at Nabble.com.

SAML authentication in OSGI continued

One problem leads to another I'm registering my service (that uses SamlHeaderInHandler for authentication of SAML tokens in the HTTP authenticate header) using DOSGI. I've included the following attributes: serviceProps.put("ws-security.signature.properties", "alice/alice.properties"); servic

Re: Problem with SamlHeaderIn

I can confirm 2.7.2 and wss4j 1.6.9 was a required to get past this issue (at least for me). Thank you Sergey. This was a great help. -- View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-SamlHeaderIn-tp5723070p5723158.html Sent from the cxf-user mailing list archive at

Re: Problem with SamlHeaderIn

Is 2.7.2 required as a version? My karaf container only offers 2.6.1. With that in place, I'm getting the same error but it looks like it is thrown from a different place. Also does it have to be a feature or could I just load a defined set of bundles provided by the feature? -- View this messa

Re: Problem with SamlHeaderIn

Hi Sergey, Are sure that "cxf-rs-security-xml" is a bundle? I get the following error from maven: [ERROR] Failed to execute goal org.apache.karaf.tooling:features-maven-plugin:2.3.0:add-features-to-repo (add-features-to-repo) on project dsp-k: Can't resolve bundle org.apache.cxf:cxf-rs-security-x

Re: Problem with SamlHeaderIn

Thanks guys. I actually had the same thought as Colm and was in process of trying that. I will try Sergey's suggestion as well and report back the results for posterity. -- View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-SamlHeaderIn-tp5723070p5723110.html Sent from t

Re: Problem with SamlHeaderIn

I've loaded the openSAML 2.5.1 jar into the container using the following command. install mvn:opensaml/opensaml/2.5.1 Then I started that bundle. However, if I have a look at its headers it is not exporting anything. Could it be that I have to embed this dependency in one of my bundles? -- Vi

Re: Problem with SamlHeaderIn

Yet another update. I apologize for using this user list as a sounding board. I got further with the debugging but don't know if I can go any further. The exception is thrown while executing OpenSAMLBootstrap.initializeXMLTooling(). It is looking for a resource called saml2-metadata-attr-config.xm

Re: Problem with SamlHeaderIn

I just wanted to add that the exception is generated when I try to step over this call in line 97 of AbstractSamlInHandler. Upon inspecting the passed tokenElement when running in my OSGI container it does not seem to be different at all from the value of tokenElement when running the rs-security t

Problem with SamlHeaderIn

This is regarding cxf version 2.7.2. My systests/rs-security builds fine and all tests pass. However, if I try to host a RESTful service in an OSGI container with a class="org.apache.cxf.rs.security.saml.SamlHeaderInHandler provider to handle authentication I get the following exception: 2013-02-1

Re: Bug in 2.7.2

Here is the link to the JIRA issue: https://issues.apache.org/jira/browse/CXF-4806 Thanks, D -- View this message in context: http://cxf.547215.n5.nabble.com/Bug-in-2-7-2-tp5722635p5722739.html Sent from the cxf-user mailing list archive at

Re: Bug in 2.7.2

I'd love to help out. However, I've never patched open source before. If you can point me to a how-to for the process please do. In the meanwhile I'll log the issue in JIRA. -- View this message in context: http://cxf.547215.n5.nabble.com/Bug-in-2-7-2-tp5722635p5722736.html Sent from the cxf-u

Re: Bug in 2.7.2

BTW I noticed that you are with Talend and I believe my company has a support contract with you. If this will help motivate a fix please let me know. -- View this message in context: http://cxf.547215.n5.nabble.com/Bug-in-2-7-2-tp5722635p5722735.html Sent from the cxf-user mailing list archive

Re: Bug in 2.7.2

Thank you for the prompt response. With all due respect, I would disagree. And the proof is in 2 places: 1. By default the code creates a JettySslFactoryConnector. Calling createConnector() on the factory returns an instance of CXFJettySslSocketConnector which extends SslSelectChannelConnector. Th

Bug in 2.7.2

I found a bug in the 2.7.2 code and would like to know how to submit it. The bug is so obvious you don't even need code to reproduce it to realize it is a bug. Observe the following code from JettHTTPServerEngine.java especially line 3: protected void retrieveListenerFactory() { if (tl

Re: SSL with DOSGi

: Friday, January 11, 2013 2:12 AM To: GE GE mailto:am...@ge.com>> Subject: Re: SSL with DOSGi Hi On 11/01/13 01:16, geecxf wrote: > Hi Sergey, > > I got it to work! I almost can't believe that it does but I'm staring at the > HTTPS response page as I'm typi

Re: SSL with DOSGi

H_NULL_.* .*_DH_anon_.* https://localhost:9093/greeter"; /> From: "Sergey Beryozkin-5 [via CXF]" mailto:ml-node+s547215n572141...@n5.nabble.com>> Date: Thursday, January 10, 2013 9:29 AM To: GE GE mailto:am...@ge.com>> Subject: Re: S

Re: SSL with DOSGi

: Re: SSL with DOSGi Hi On 10/01/13 17:07, geecxf wrote: > Hi Sergey, > > Thanks for the prompt response. The more I read through the CXF DOSGi code > the more your revelation makes sense. It seems like the only configuration > file that affects cxf.dosgi.dsw is the cxf-dsw.cfg through

Re: SSL with DOSGi

t;> Date: Thursday, January 10, 2013 9:29 AM To: GE GE mailto:am...@ge.com>> Subject: Re: SSL with DOSGi On 10/01/13 17:27, Sergey Beryozkin wrote: > Hi > On 10/01/13 17:07, geecxf wrote: >> Hi Sergey, >> >> Thanks for the prompt response. The more I read through t

Re: SSL with DOSGi

Hi Sergey, Thanks for the prompt response. The more I read through the CXF DOSGi code the more your revelation makes sense. It seems like the only configuration file that affects cxf.dosgi.dsw is the cxf-dsw.cfg through Felix FileInstall. However, I can't see any properties that affects the def

SSL with DOSGi

I would like to host an SSL protected endpoint using CXF DOSGi and configure an absolute endpoint URL using the org.apache.cxf.rs.address configuration property. I have searched through this list and am aware that it is possible to secure a web service with SSL by specifying a relative URL endpoin