You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Eduardo Burgos <eb...@gmail.com> on 2007/03/23 18:37:29 UTC

HttpConsumerEndpoint, security issue

Hi,


This is regarding HttpConsumerEndpoint class, which is
HttpSoapConsumerEndpoint's superclass. I tried to dynamically deploy a
HttpSoapConsumerEndpoint into a servicemix-http, it worked very well, but I
noticed some different behavior compared to the old HttpEndpoint. If I used
HttpEndpoint, every time I log in using http, the underlying
NormalizedMessage carries in the securitySubject a Principal that identifies
the user, this is not the case with
HttpSoapConsumerEndpoint/HttpConsumerEndpoint. Since those new
HttpEndpointTypes now use a marshaler (which is by default the
DefaultHttpConsumerMarshaler) then Im not sure if this is actually intended.
Is it intended that the HttpConsumerEndpoint is left without this security
feature so that I have to actually implement it in a new Marshaler?

I found 2 solutions:
1) I can build a new HttpConsumerMarshaler and handle the createExchange
method so that it uses  the request and inserts a SecuritySubject in the
MessageExchange that its just about to create. That would work, however, I
still think that security should be a little more servicemix native.

2) I would modify HttpConsumerEndpoint.java in
org.apache.servicemix.http.endpoints.HttpConsumerEndpoint and insert the
following lines between lines 217 and 218 which are respectively:
217-  exchange = createExchange(request);
218-  locks.put(exchage.getExchangeId(), cont);


proposed lines:

217-  exchange = createExchange(request);
218-  if (request.getUserPrincipal() != null) {
219-          if (request.getUserPrincipal() instanceof JaasJettyPrincipal)
{
220-                          Subject subject = ((JaasJettyPrincipal)
request.getUserPrincipal()).getSubject();
221-                          context.getInMessage().setSubject(subject);
222-          } else {
223-                           context.getInMessage().addPrincipal(
request.getUserPrincipal());
224-         }
225-  }
226-   locks.put(exchage.getExchangeId(), cont);


I chose option 2 by modifying HttpConsumerEndpoint's code until there is a
final solution.

Any comments? Guillaume?


Regards,

Eduardo Burgos

Re: install repository monitoring at ServiceMix startup (bug ?)

Posted by Guillaume Nodet <gn...@gmail.com>.
You can not use both JBI packaging and
configure endpoints in the servicemix.xml configuration file.
The reason is the components / endpoints in the servicemix.xml
file must have all the needed classes in their classpath.
So installing the component won't help, as they are in separate
classloaders.

On 3/23/07, Dominique DE VITO <do...@thalesgroup.com> wrote:
>
> At first sight, the pb looks like this: ServiceMix seems not to look at
> "install" repository at startup time, but after (looks too late).
>
> I am using <http:endpoint> in my servicemix.xml definition.
> And servicemix-http-3.1-incubating-installer.zip is in the "install"
> repository + I moved components/lib into lib/optional.
> I launched bin\servicemix servicemix.xml
>
> But while starting, ServiceMix write:
> DEBUG - XBeanNamespaceHandler          - Could not find resource:
> META-INF/services/org/xbean/spring/http/servicemix.apache.org/http/1.0
> Caught: org.springframework.beans.factory.BeanDefinitionStoreException:
> Unrecognized xbean namespace mapping:
> http://servicemix.apache.org/http/1.0
> org.springframework.beans.factory.BeanDefinitionStoreException:
> Unrecognized xbean namespace mapping:
> http://servicemix.apache.org/http/1.0
>         at
>
> org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.parseBeanFromExtensionElement
> (XBeanNamespaceHandler.java:262)
>
> So, ServiceMix seems not to look at "install" repository at startup
> time, but after (too late).
>
> The configuration seems correct : <sm:container id="jbi" ...
>   installationDirPath="./install"
>   monitorInstallationDirectory="true">
>
> And the servicemix.xml works as expected, when I unzip all install ZIP
> files into lib repository.
>
> Is it a bug ? If not, why not scan at startup the "install" repository
> and then, run servicemix.xml ?
>
> Thanks.
>
> Dominique
>
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

install repository monitoring at ServiceMix startup (bug ?)

Posted by Dominique DE VITO <do...@thalesgroup.com>.
At first sight, the pb looks like this: ServiceMix seems not to look at 
"install" repository at startup time, but after (looks too late).

I am using <http:endpoint> in my servicemix.xml definition.
And servicemix-http-3.1-incubating-installer.zip is in the "install" 
repository + I moved components/lib into lib/optional.
I launched bin\servicemix servicemix.xml

But while starting, ServiceMix write:
DEBUG - XBeanNamespaceHandler          - Could not find resource: 
META-INF/services/org/xbean/spring/http/servicemix.apache.org/http/1.0
Caught: org.springframework.beans.factory.BeanDefinitionStoreException: 
Unrecognized xbean namespace mapping: http://servicemix.apache.org/http/1.0
org.springframework.beans.factory.BeanDefinitionStoreException: 
Unrecognized xbean namespace mapping: http://servicemix.apache.org/http/1.0
        at 
org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.parseBeanFromExtensionElement(XBeanNamespaceHandler.java:262)

So, ServiceMix seems not to look at "install" repository at startup 
time, but after (too late).

The configuration seems correct : <sm:container id="jbi" ...
  installationDirPath="./install"
  monitorInstallationDirectory="true">

And the servicemix.xml works as expected, when I unzip all install ZIP 
files into lib repository.

Is it a bug ? If not, why not scan at startup the "install" repository 
and then, run servicemix.xml ?

Thanks.

Dominique



Re: HttpConsumerEndpoint, security issue

Posted by Eduardo Burgos <eb...@gmail.com>.
By the way, the lines I inserted were taken by the
ConsumerProcessor.java(lines 170-177), thats the point where
HttpEndpoint used to do the job since
ConsumerProcessor was the HttpBridgeServlet's processor, but now since the
processor is the HttpConsumerEndpoint itself then that code no longer
executes if you choose the new Endpoints.



On 3/23/07, Eduardo Burgos <eb...@gmail.com> wrote:
>
> Hi,
>
>
> This is regarding HttpConsumerEndpoint class, which is
> HttpSoapConsumerEndpoint's superclass. I tried to dynamically deploy a
> HttpSoapConsumerEndpoint into a servicemix-http, it worked very well, but I
> noticed some different behavior compared to the old HttpEndpoint. If I used
> HttpEndpoint, every time I log in using http, the underlying
> NormalizedMessage carries in the securitySubject a Principal that identifies
> the user, this is not the case with
> HttpSoapConsumerEndpoint/HttpConsumerEndpoint. Since those new
> HttpEndpointTypes now use a marshaler (which is by default the
> DefaultHttpConsumerMarshaler) then Im not sure if this is actually intended.
> Is it intended that the HttpConsumerEndpoint is left without this security
> feature so that I have to actually implement it in a new Marshaler?
>
> I found 2 solutions:
> 1) I can build a new HttpConsumerMarshaler and handle the createExchange
> method so that it uses  the request and inserts a SecuritySubject in the
> MessageExchange that its just about to create. That would work, however, I
> still think that security should be a little more servicemix native.
>
> 2) I would modify HttpConsumerEndpoint.java in
> org.apache.servicemix.http.endpoints.HttpConsumerEndpoint and insert the
> following lines between lines 217 and 218 which are respectively:
> 217-  exchange = createExchange(request);
> 218-  locks.put(exchage.getExchangeId(), cont);
>
>
> proposed lines:
>
> 217-  exchange = createExchange(request);
> 218-  if (request.getUserPrincipal() != null) {
> 219-          if (request.getUserPrincipal () instanceof
> JaasJettyPrincipal) {
> 220-                          Subject subject = ((JaasJettyPrincipal)
> request.getUserPrincipal()).getSubject();
> 221-                          context.getInMessage().setSubject(subject);
> 222-          } else {
> 223-                           context.getInMessage().addPrincipal(
> request.getUserPrincipal());
> 224-         }
> 225-  }
> 226-   locks.put(exchage.getExchangeId(), cont);
>
>
> I chose option 2 by modifying HttpConsumerEndpoint's code until there is a
> final solution.
>
> Any comments? Guillaume?
>
>
> Regards,
>
> Eduardo Burgos
>

Re: HttpConsumerEndpoint, security issue

Posted by Eduardo Burgos <eb...@gmail.com>.
created as  https://issues.apache.org/activemq/browse/SM-895 with attached
diff file


I changed the proposed lines to:

if (request.getUserPrincipal() != null) {
        if (request.getUserPrincipal() instanceof JaasJettyPrincipal) {
              Subject subject = ((JaasJettyPrincipal)
request.getUserPrincipal()).getSubject();
                        exchange.getMessage
("in").setSecuritySubject(subject);
        }
 }


So that it could actually compile :P

On 3/23/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Could you please raise a JIRA and attahc your patch
> as a diff file if possible ? Thanks !
>
> On 3/23/07, Eduardo Burgos <eb...@gmail.com> wrote:
> >
> > Hi,
> >
> >
> > This is regarding HttpConsumerEndpoint class, which is
> > HttpSoapConsumerEndpoint's superclass. I tried to dynamically deploy a
> > HttpSoapConsumerEndpoint into a servicemix-http, it worked very well,
> but
> > I
> > noticed some different behavior compared to the old HttpEndpoint. If I
> > used
> > HttpEndpoint, every time I log in using http, the underlying
> > NormalizedMessage carries in the securitySubject a Principal that
> > identifies
> > the user, this is not the case with
> > HttpSoapConsumerEndpoint/HttpConsumerEndpoint. Since those new
> > HttpEndpointTypes now use a marshaler (which is by default the
> > DefaultHttpConsumerMarshaler) then Im not sure if this is actually
> > intended.
> > Is it intended that the HttpConsumerEndpoint is left without this
> security
> > feature so that I have to actually implement it in a new Marshaler?
> >
> > I found 2 solutions:
> > 1) I can build a new HttpConsumerMarshaler and handle the createExchange
> > method so that it uses  the request and inserts a SecuritySubject in the
> > MessageExchange that its just about to create. That would work, however,
> I
> > still think that security should be a little more servicemix native.
> >
> > 2) I would modify HttpConsumerEndpoint.java in
> > org.apache.servicemix.http.endpoints.HttpConsumerEndpoint and insert the
> > following lines between lines 217 and 218 which are respectively:
> > 217-  exchange = createExchange(request);
> > 218-  locks.put(exchage.getExchangeId(), cont);
> >
> >
> > proposed lines:
> >
> > 217-  exchange = createExchange(request);
> > 218-  if (request.getUserPrincipal() != null) {
> > 219-          if (request.getUserPrincipal() instanceof
> > JaasJettyPrincipal)
> > {
> > 220-                          Subject subject = ((JaasJettyPrincipal)
> > request.getUserPrincipal()).getSubject();
> > 221-                          context.getInMessage
> ().setSubject(subject);
> > 222-          } else {
> > 223-                           context.getInMessage().addPrincipal(
> > request.getUserPrincipal());
> > 224-         }
> > 225-  }
> > 226-   locks.put(exchage.getExchangeId(), cont);
> >
> >
> > I chose option 2 by modifying HttpConsumerEndpoint's code until there is
> a
> > final solution.
> >
> > Any comments? Guillaume?
> >
> >
> > Regards,
> >
> > Eduardo Burgos
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Architect, LogicBlaze (http://www.logicblaze.com/)
> Blog: http://gnodet.blogspot.com/
>

Re: HttpConsumerEndpoint, security issue

Posted by Guillaume Nodet <gn...@gmail.com>.
Could you please raise a JIRA and attahc your patch
as a diff file if possible ? Thanks !

On 3/23/07, Eduardo Burgos <eb...@gmail.com> wrote:
>
> Hi,
>
>
> This is regarding HttpConsumerEndpoint class, which is
> HttpSoapConsumerEndpoint's superclass. I tried to dynamically deploy a
> HttpSoapConsumerEndpoint into a servicemix-http, it worked very well, but
> I
> noticed some different behavior compared to the old HttpEndpoint. If I
> used
> HttpEndpoint, every time I log in using http, the underlying
> NormalizedMessage carries in the securitySubject a Principal that
> identifies
> the user, this is not the case with
> HttpSoapConsumerEndpoint/HttpConsumerEndpoint. Since those new
> HttpEndpointTypes now use a marshaler (which is by default the
> DefaultHttpConsumerMarshaler) then Im not sure if this is actually
> intended.
> Is it intended that the HttpConsumerEndpoint is left without this security
> feature so that I have to actually implement it in a new Marshaler?
>
> I found 2 solutions:
> 1) I can build a new HttpConsumerMarshaler and handle the createExchange
> method so that it uses  the request and inserts a SecuritySubject in the
> MessageExchange that its just about to create. That would work, however, I
> still think that security should be a little more servicemix native.
>
> 2) I would modify HttpConsumerEndpoint.java in
> org.apache.servicemix.http.endpoints.HttpConsumerEndpoint and insert the
> following lines between lines 217 and 218 which are respectively:
> 217-  exchange = createExchange(request);
> 218-  locks.put(exchage.getExchangeId(), cont);
>
>
> proposed lines:
>
> 217-  exchange = createExchange(request);
> 218-  if (request.getUserPrincipal() != null) {
> 219-          if (request.getUserPrincipal() instanceof
> JaasJettyPrincipal)
> {
> 220-                          Subject subject = ((JaasJettyPrincipal)
> request.getUserPrincipal()).getSubject();
> 221-                          context.getInMessage().setSubject(subject);
> 222-          } else {
> 223-                           context.getInMessage().addPrincipal(
> request.getUserPrincipal());
> 224-         }
> 225-  }
> 226-   locks.put(exchage.getExchangeId(), cont);
>
>
> I chose option 2 by modifying HttpConsumerEndpoint's code until there is a
> final solution.
>
> Any comments? Guillaume?
>
>
> Regards,
>
> Eduardo Burgos
>



-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/