cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From geecxf <am...@ge.com>
Subject Re: SSL with DOSGi
Date Fri, 11 Jan 2013 18:27:27 GMT
Hi Sergey,

After stepping through the code here is my understanding of how this works (I am writing it
down for posterity). The SpringBus bean instantiated via Spring DM sets the default bus in
BusFactory. SpringBus extends ExtensionManagerBus which in turn extends CXFBusImpl. The instantiation
code in CXFBusImpl calls the method possiblySetDefaultBus() which is where the magic happens.
The default bus appears to be specific to the common thread that the code runs on. Meaning
that you could set a different default bus for a different thread and thus support entirely
different bus configurations in different bundles.

It would be great to have Dan (I'm assuming he's the developer) weigh in on this.

Once again, thanks for the help and have a great weekend.

D

From: "Sergey Beryozkin-5 [via CXF]" <ml-node+s547215n5721441h83@n5.nabble.com<mailto:ml-node+s547215n5721441h83@n5.nabble.com>>
Date: Friday, January 11, 2013 2:12 AM
To: GE GE <amiri@ge.com<mailto:amiri@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 typing this email. Thank you for pointing in me in the right direction.
>

Sorry I did not answer yesterday, I had some vague idea that having the
bus configured explicitly within the application context may work, and
I'm glad to see you've made it work,



> Of course, I had to take a detour to learn about spring during which I spent at least
an hour of time chasing my tail till I realized that I had to enable this feature in Karaf
with:
>
>> feature:install spring
>> feature:install spring-dm
>
> I have included these details and the contents of my META-INF/spring/spring.xml file
below in the hope that this will be useful to someone else. I reused the keystore in samples/jax_rs/basic_https.
I don't however fully understand why this solution works. My best guess, based on my feeble
understanding of the BusFactory code, is that it somehow knows how to search the for the SpringBus
instance I loaded via the bean in my spring DM file. I still haven't figured out how to run
this code in the debugger (I'm very new to development in the Java world) but that will be
my next challenge. In the meanwhile if you can help shed some light on why it's working I
would appreciate it.

I'm not exactly sure myself too, I guess only Dan knows why it works, it
is magic :-),

 > <httpj:engine-factory bus="cxf">

is probably the main link between the default bus loaded within the
context and the Jetty engine.

By the way, try

"<cxf:bus id="myid"/>"
<httpj:engine-factory bus="myid">

This may let you drop the original bus configuration

Cheers, Sergey

>
> Here's my spring.xml:
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <!--
>
>    Licensed to the Apache Software Foundation (ASF) under one
>
>    or more contributor license agreements. See the NOTICE file
>
>    distributed with this work for additional information
>
>    regarding copyright ownership. The ASF licenses this file
>
>    to you under the Apache License, Version 2.0 (the
>
>    "License"); you may not use this file except in compliance
>
>    with the License. You may obtain a copy of the License at
>
>
>    http://www.apache.org/licenses/LICENSE-2.0
>
>
>    Unless required by applicable law or agreed to in writing,
>
>    software distributed under the License is distributed on an
>
>    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>
>    KIND, either express or implied. See the License for the
>
>    specific language governing permissions and limitations
>
>    under the License.
>
> -->
>
> <beans xmlns="http://www.springframework.org/schema/beans"
>
> xmlns:beans="http://www.springframework.org/schema/beans"
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xmlns:osgi="http://www.springframework.org/schema/osgi"
>
> xmlns:sec="http://cxf.apache.org/configuration/security"
>
> xmlns:http="http://cxf.apache.org/transports/http/configuration"
>
> xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
>
> xsi:schemaLocation="
>
> http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
>
>      http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd
>
>      http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd
>
> http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd
>
> http://cxf.apache.org/transports/http-jetty/configuration http://cxf.apache.org/schemas/configuration/http-jetty.xsd">
>
>
> <!--<import resource="classpath:META-INF/cxf/cxf.xml"/>
>
> <import resource="classpath:META-INF/cxf/cxf-extension-xml.xml"/>
>
> <import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>-->
>
> <!-- Sanity check to make sure Spring DM is working.  -->
>
> <bean id="hello" class="org.apache.cxf.dosgi.samples.greeter.impl.rest.PrintHello"
init-method="init"/>
>
> <bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus" destroy-method="shutdown"/>
>
>
>      <bean id="org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor"
>
>          class="org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor"/>
>
>      <bean id="org.apache.cxf.bus.spring.Jsr250BeanPostProcessor"
>
>          class="org.apache.cxf.bus.spring.Jsr250BeanPostProcessor"/>
>
>      <bean id="org.apache.cxf.bus.spring.BusExtensionPostProcessor"
>
>          class="org.apache.cxf.bus.spring.BusExtensionPostProcessor"/>
>
>
> <httpj:engine-factory bus="cxf">
>
> <httpj:engine port="9093">
>
> <httpj:tlsServerParameters>
>
> <sec:keyManagers keyPassword="skpass">
>
> <sec:keyStore file="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
>
> </sec:keyManagers>
>
> <sec:trustManagers>
>
> <sec:keyStore file="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
>
> </sec:trustManagers>
>
> <sec:cipherSuitesFilter>
>
> <!-- these filters ensure that a ciphersuite with
>
>    export-suitable or null encryption is used,
>
>    but exclude anonymous Diffie-Hellman key change as
>
>    this is vulnerable to man-in-the-middle attacks -->
>
> <sec:include>.*_EXPORT_.*</sec:include>
>
> <sec:include>.*_EXPORT1024_.*</sec:include>
>
> <sec:include>.*_WITH_DES_.*</sec:include>
>
> <sec:include>.*_WITH_AES_.*</sec:include>
>
> <sec:include>.*_WITH_NULL_.*</sec:include>
>
> <sec:exclude>.*_DH_anon_.*</sec:exclude>
>
> </sec:cipherSuitesFilter>
>
> <sec:clientAuthentication want="false" required="false"/>
>
> </httpj:tlsServerParameters>
>
> </httpj:engine>
>
> </httpj:engine-factory>
>
> <!--<httpj:engine-factory bus="cxf">
>
>      <httpj:identifiedTLSServerParameters id="secure">
>
>        <httpj:tlsServerParameters>
>
>          <sec:keyManagers keyPassword="skpass">
>
>            <sec:keyStore type="JKS" password="sspass" file="certs/serviceKeystore.jks"/>
>
>          </sec:keyManagers>
>
>        </httpj:tlsServerParameters>
>
>      </httpj:identifiedTLSServerParameters>
>
>      <httpj:engine port="9093">
>
>        <httpj:tlsServerParametersRef id="secure" />
>
>        <httpj:threadingParameters minThreads="5"
>
>                                  maxThreads="15" />
>
>        <httpj:connector>
>
>          <beans:bean class="org.eclipse.jetty.server.bio.SocketConnector">
>
>            <beans:property name="port" value="9093" />
>
>          </beans:bean>
>
>        </httpj:connector>
>
>        <httpj:handlers>
>
>          <beans:bean class="org.eclipse.jetty.server.handler.DefaultHandler"/>
>
>        </httpj:handlers>
>
>        <httpj:sessionSupport>true</httpj:sessionSupport>
>
>      </httpj:engine>
>
> </httpj:engine-factory>-->
>
> <osgi:service interface="org.apache.cxf.dosgi.samples.greeter.rest.GreeterService">
>
> <osgi:service-properties>
>
> <entry key="service.exported.interfaces" value="*" />
>
> <entry key="service.exported.configs" value="org.apache.cxf.rs" />
>
> <entry key="service.exported.intents" value="HTTP" />
>
> <entry key="org.apache.cxf.rs.address" value="https://localhost:9093/greeter" />
>
> </osgi:service-properties>
>
> <bean class="org.apache.cxf.dosgi.samples.greeter.impl.rest.GreeterServiceImpl" />
>
> </osgi:service>
>
> </beans>
>
>
> From: "Sergey Beryozkin-5 [via CXF]"<[hidden email]</user/SendEmail.jtp?type=node&node=5721441&i=0><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721441&i=1>>>
> Date: Thursday, January 10, 2013 9:29 AM
> To: GE GE<[hidden email]</user/SendEmail.jtp?type=node&node=5721441&i=2><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721441&i=3>>>
> 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 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 default bus when using an absolute addresses.
>>>
>>> So it looks like I would have to affect the BusFactory class which
>>> seems to read some bus configuration from external sources. Which begs
>>> the question:
>>>
>>> Could I alter the default bus configuration to support https though a
>>> META-INF/cxf/cxf.xml file in the manner described here
>>> http://cxf.apache.org/docs/configuration.html? Then build a new
>>> cxf-dosgi-ri-singlebundle-distribution that by default will create
>>> HTTPS endpoints instead of HTTP when specifying absolute addresses?
>>> Would this approach work?
>>>
>>
>> I wonder if that will work even if you declare cxf:bus in your
>> application context, alongside http-jetty configuration and DOSGi will
>> pick up it, but I'm not sure; you may need to experiment, but I doubt
>> that rebuilding a single bundle distro would be the right approach,
>> ideally, there was some way to get DOSGi picking up the SSL-aware
>> default bus
>>> My follow-up question is that if the approach described above works,
>>> it is obviously a hack. Was there a vision for SSL support when using
>>> absolute addresses? What would such a feature look like? Or is any
>>> solution OK as long as it does not violate the DOSGi specification?
>>
>> As far as I recall, no support for HTTPS was on the map at a time,
>>
>> By the way, why using OSGI HTTP Service does meet the requirements ?
>>
> does *not* meet ?
>
>> Cheers, Sergey
>>
>>>
>>> Thanks,
>>>
>>> D
>>>
>>> From: "Sergey Beryozkin-5 [via
>>> CXF]"<[hidden email]</user/SendEmail.jtp?type=node&node=5721416&i=0><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721416&i=1>>>
>>>
>>> Date: Thursday, January 10, 2013 8:31 AM
>>> To: GE GE<[hidden email]</user/SendEmail.jtp?type=node&node=5721416&i=2><mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=5721416&i=3>>>
>>> Subject: Re: SSL with DOSGi
>>>
>>> Or rather, no one has looked yet into trying to get the bus aware of
>>> such configuration found and selected somehow when absolute
>>> org.apache.cxf.rs/ws.addresses are used :-)
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/SSL-with-DOSGi-tp5721344p5721413.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion below:
>
> NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
>


________________________________
If you reply to this email, your message will be added to the discussion below:
http://cxf.547215.n5.nabble.com/SSL-with-DOSGi-tp5721344p5721441.html
To unsubscribe from SSL with DOSGi, click here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5721344&code=YW1pcmlAZ2UuY29tfDU3MjEzNDR8LTE3ODgxMjU0NzM=>.
NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://cxf.547215.n5.nabble.com/SSL-with-DOSGi-tp5721344p5721484.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message