karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: Securing shell commands
Date Mon, 12 Nov 2012 19:30:09 GMT
As far I know you can use JAAS login modules without JVM level security manager. It's only
metter of creating the login context/module and so on. However usage of SecurityManager gives
us another big benefit - possibility to integrate Karaf security with OSGi level permissions.

What I see in another IAuthService is that nobody will support that. Every single projects
which could be possibly integrated with Karaf will need to bridge all security things.  I
know you can implement that in Camel or ActiveMQ, but from other hand did you get earlier
implementation of similar service for SMX3? Even if you will have this then in 95% of cases
you will bridge JAAS subject from Camel to IAuthService in Karaf which will hide JAAS. You
can not guarantee that xml-security project will support karaf security layer. Thus usage
of WS-Security will always require 3rd party code to be produced. Every time.
If you would like to do things like integrating security layers from different projects to
run all together then I think the best place for that is ServiceMix, not Karaf - as it was
before.

The XML structure you shown before looks like configuration of login module for me. What we
really need is pre-defined list of possible actions to execute (in other words permissions),
like BundleStopPermission(bundle), BundleListPermission(framework/region). Only one standard
I know which supports that is JAAS.
We are always running under OSGi. Here we already have a service to use - it's called PermissionAdmin.
As we are lightweight OSGi container we definitely should rely on this, not some custom parts.

Best regards,
Lukasz

Wiadomość napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. 14:36:

> Could you explain how you would do that with pure JAAS without requiring a
> security manager ?
> Security manager is not always the best option.  And I haven't seen many
> projects forcing its use for simple authorization.
> 
> I agree that xml is not perfect, especially in that case, the main reason,
> but a flat property file with ordering is not easy to write either.
> Another option would be to use a url which would point to the xml, or text
> base file.  But properties are map based with no ordering guarantee.
> 
> 
> On Mon, Nov 12, 2012 at 1:30 PM, Łukasz Dywicki <luke@code-house.org> wrote:
> 
>> I don't think that storing XML data inside flat configuration file is
>> something I would like to see in karaf.
>> 
>> Nobody will be able to edit that to be honest. Implementation of
>> wildcards/RBAC can be done easily with JAAS LoginModule. So from my point
>> of view it's -1.
>> I see no need for introducing another custom interface.
>> 
>> Best regards,
>> Lukasz
>> 
>> Wiadomość napisana przez Guillaume Nodet w dniu 6 lis 2012, o godz. 11:14:
>> 
>>> I've just committed the changes to 2.3.x branch.
>>> I'll try to backport it to trunk asap.
>>> 
>>> 
>>> On Fri, Nov 2, 2012 at 8:28 AM, Guillaume Nodet <gnodet@gmail.com>
>> wrote:
>>> 
>>>> That's kind of the reason why I did not decide to put that method in the
>>>> interface, because retrieval of the subject will certainly depend where
>> you
>>>> come from.
>>>> If we add such providers, the camel one would have to use a thread local
>>>> one anyway to be able to access the exchange, so I'm not really
>> convinced
>>>> it really helps.  It's not more difficult to store the exchange in a
>> thread
>>>> local and use a provider than just extracting the subject from the
>> exchange
>>>> and pass it to the authorization service.
>>>> Also, if we have mutliple providers, I fear we won't be in control: we'd
>>>> have to use all the existing providers to find the subjects and combine
>>>> them when there are multiple ones.  The consequence is that if you don't
>>>> want inferences from karaf and camel, you have to use different set of
>>>> roles.  I guess that's not really a problem per se, but overall, i
>>>> currently fail to see the benefits.
>>>> 
>>>> 
>>>> On Thu, Nov 1, 2012 at 3:14 PM, Kurt Westerfeld <
>> kurt.westerfeld@gmail.com
>>>>> wrote:
>>>> 
>>>>> I am in favor of a private interface that has a default implementation,
>>>>> and one that shiro could provide.
>>>>> 
>>>>> Could you add a "getCurrentSubject()" to your interface, or add another
>>>>> interface that has a default implementation for karaf commands?  For
>>>>> example:
>>>>> 
>>>>>  public interface SubjectContext {
>>>>>     Subject getCurrentSubject();
>>>>>  }
>>>>> 
>>>>> Note: when utilizing Subject.doAs(), as karaf commands do, the
>> "current"
>>>>> subject is held within a threadlocal within
>>>>> AccessControlContext/SubjectDomainCombiner, so the default
>> implementation
>>>>> for SubjectContext.getCurrentSubject() can delegate to that.
>>>>> 
>>>>> My feeling here is that there is a "SubjectContextProvider" SPI that
>>>>> needs to be 1:N within a Karaf implementation to obtain a subject.
>> Within
>>>>> Camel, as an example, the current message exchange holds a subject as
a
>>>>> specialized property.
>>>>> 
>>>>> On Oct 31, 2012, at 7:24 PM, Guillaume Nodet <gnodet@gmail.com>
wrote:
>>>>> 
>>>>>> Because that would be incompatible and require much more work.  It's
a
>>>>>> tradeoff I guess and I'm currently not yet convinced that it's really
>>>>>> needed, but as I said, I don't have any real objection at this point.
>>>>>> But what I'm working on is a real need, so we can revisit the
>> underlying
>>>>>> implementation later, that's not really a problem as the interface
>> would
>>>>>> not even have to change, while we can't really change the underlying
>>>>>> security implementation in a minor release such as 2.3 or 2.4 or
just
>>>>>> before releasing 3.0 ...
>>>>>> 
>>>>>> On Wed, Oct 31, 2012 at 9:58 PM, Andrei Pozolotin <
>>>>>> andrei.pozolotin@gmail.com> wrote:
>>>>>> 
>>>>>>> in this case, why not drop jaas altogether,
>>>>>>> and use shiro everywhere in karaf instead of jaas,
>>>>>>> for everything, not just for "shell commands"?
>>>>>>> 
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: Securing shell commands
>>>>>>> From: Guillaume Nodet <gnodet@gmail.com> <gnodet@gmail.com>
>>>>>>> To: dev@karaf.apache.org
>>>>>>> Date: Wed 31 Oct 2012 02:47:58 AM CDT
>>>>>>> 
>>>>>>> Because Kurt noted that obtaining an authenticated JAAS subject
can
>> be
>>>>>>> difficult in some contexts and opening the interface makes it
more
>>>>> reusable.
>>>>>>> If you can access the JAAS subject, one would use the
>>>>>>>  void checkPermission(Subject subject, String permission);
>>>>>>> 
>>>>>>> I'm not sure there's a real use case for another third set of
methods
>>>>> which
>>>>>>> would use a List<Principal>.
>>>>>>> 
>>>>>>> On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin <
>>>>> andrei.pozolotin@gmail.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> I mean why
>>>>>>> 
>>>>>>> void checkPermission(List<String> principals, String permission);
>>>>>>> 
>>>>>>> is not using
>>>>>>> 
>> http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html
>>>>>>> 
>>>>>>> ?
>>>>>>> 
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: Securing shell commands
>>>>>>> From: Achim Nierbeck <bcanhome@googlemail.com> <
>>>>> bcanhome@googlemail.com>
>>>>>>> To: dev@karaf.apache.org
>>>>>>> Date: Tue 30 Oct 2012 04:27:40 PM CDT
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I'm unsure about what you mean by this, but the UserPrincipal
is a
>>>>>>> java.security.Principal implementation.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>> https://github.com/apache/karaf/blob/trunk/jaas/boot/src/main/java/org/apache/karaf/jaas/boot/principal/UserPrincipal.java
>>>>>>> 
>>>>>>> Oh and by the way +1 for this concept :-D
>>>>>>> 
>>>>>>> regards, Achim
>>>>>>> 
>>>>>>> 2012/10/30 Andrei Pozolotin <andrei.pozolotin@gmail.com>
<
>>>>> andrei.pozolotin@gmail.com>:
>>>>>>> 
>>>>>>> andhttp://
>>>>> docs.oracle.com/javase/6/docs/api/java/security/Principal.html
>>>>>>> 
>>>>>>> is wrong, because ...?
>>>>>>> 
>>>>>>> 
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: Securing shell commands
>>>>>>> From: Guillaume Nodet <gnodet@gmail.com> <gnodet@gmail.com>
>>>>>>> To: dev@karaf.apache.org
>>>>>>> Date: Tue 30 Oct 2012 03:20:48 PM CDT
>>>>>>> 
>>>>>>> Permissions in JAAS can't be used with wildcards or permission
trees
>>>>>>> 
>>>>>>> for
>>>>>>> 
>>>>>>> example.
>>>>>>> You'd have to define a permission for each command without any
way to
>>>>>>> simplify the configuration.
>>>>>>> 
>>>>>>> On Tue, Oct 30, 2012 at 8:58 PM, Andrei Pozolotin <
>>>>> andrei.pozolotin@gmail.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> what is the reason to stay away from
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> http://docs.oracle.com/javase/6/docs/api/java/security/Permission.html
>>>>>>> 
>>>>>>> in
>>>>>>> 
>>>>>>> void checkPermission(Subject subject, String permission);
>>>>>>> 
>>>>>>> vs
>>>>>>> 
>>>>>>> void checkPermission(Subject subject, Permission permission);
>>>>>>> 
>>>>>>> ?
>>>>>>> 
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: Securing shell commands
>>>>>>> From: Guillaume Nodet <gnodet@gmail.com> <gnodet@gmail.com>
<
>>>>> gnodet@gmail.com> <gnodet@gmail.com>
>>>>>>> To: dev@karaf.apache.org, kurt@westerfeld.com
>>>>>>> Date: Tue 30 Oct 2012 11:03:14 AM CDT
>>>>>>> 
>>>>>>> So what about a service defined like the following:
>>>>>>> 
>>>>>>> public interface AuthorizationService {
>>>>>>> 
>>>>>>>  List<String> getPrincipals(Subject subject);
>>>>>>> 
>>>>>>>  void checkPermission(Subject subject, String permission);
>>>>>>> 
>>>>>>>  boolean isPermitted(Subject subject, String permission);
>>>>>>> 
>>>>>>>  void checkRole(Subject subject, String role);
>>>>>>> 
>>>>>>>  boolean hasRole(Subject subject, String role);
>>>>>>> 
>>>>>>>  void checkPermission(List<String> principals, String permission);
>>>>>>> 
>>>>>>>  boolean isPermitted(List<String> principals, String permission);
>>>>>>> 
>>>>>>>  void checkRole(List<String> principals, String role);
>>>>>>> 
>>>>>>>  boolean hasRole(List<String> principals, String role);
>>>>>>> 
>>>>>>> }
>>>>>>> 
>>>>>>> All the methods taking a subject delegate to the corresponding
method
>>>>>>> 
>>>>>>> using
>>>>>>> 
>>>>>>> a List<String> via a call to getPrincipals(Subject).
>>>>>>> The translation is done by appending the Principal class name
>>>>>>> 
>>>>>>> (usually a
>>>>>>> 
>>>>>>> org.apache.karaf.jaas.boot.principal.RolePrincipal) with the
>> principal
>>>>>>> name, separated by a column, so something like:
>>>>>>> org.apache.karaf.jaas.boot.principal.RolePrincipal:karaf
>>>>>>> 
>>>>>>> Thoughts ?
>>>>>>> 
>>>>>>> On Tue, Oct 30, 2012 at 4:32 PM, Guillaume Nodet <gnodet@gmail.com>
>> <
>>>>> gnodet@gmail.com> <
>>>>>>> 
>>>>>>> gnodet@gmail.com> wrote:
>>>>>>> 
>>>>>>> Ok, that totally makes sense to me.
>>>>>>> Let me enhance the interface to provide more non jaas tied methods
>>>>>>> 
>>>>>>> and get
>>>>>>> 
>>>>>>> back to this list.
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Oct 30, 2012 at 3:29 PM, Kurt Westerfeld <
>>>>>>> 
>>>>>>> kurt.westerfeld@gmail.com> wrote:
>>>>>>> 
>>>>>>> I was thinking of Shiro as a provider for the authorization engine,
>>>>>>> 
>>>>>>> not as
>>>>>>> 
>>>>>>> the actual interfaces.
>>>>>>> 
>>>>>>> I actually think the container should provide a default
>>>>>>> 
>>>>>>> implementation for
>>>>>>> 
>>>>>>> security concerns.  If you look at JEE, there are definitely
>> standards
>>>>>>> there, which haven't worked out perfectly, but at least are
>>>>>>> 
>>>>>>> constructs for
>>>>>>> 
>>>>>>> people to build on.  In the OSGi world, I believe the container
>>>>>>> 
>>>>>>> should be
>>>>>>> 
>>>>>>> configurable to provide a default realm (it is in Karaf), and
there
>>>>>>> 
>>>>>>> should
>>>>>>> 
>>>>>>> be an easy mapping from the application to the container's security
>>>>>>> 
>>>>>>> (this
>>>>>>> 
>>>>>>> isn't hard to do, but since it is left up to the developer, I
think
>>>>>>> 
>>>>>>> it's
>>>>>>> 
>>>>>>> not done that well).
>>>>>>> 
>>>>>>> For example, if I decide to tie my Karaf implementation to LDAP,
I
>> can
>>>>>>> provide config to do that.  Now, I'd like it if by doing that,
my
>>>>>>> application is wired to that LDAP provider and I just move along
to
>>>>>>> 
>>>>>>> other
>>>>>>> 
>>>>>>> concerns.  If I want to do that myself, I can make a separate
choice
>>>>>>> 
>>>>>>> on
>>>>>>> 
>>>>>>> the
>>>>>>> login realm to tie my application to it's own config.
>>>>>>> 
>>>>>>> The main point I was making, though, is that your interface requires
>> a
>>>>>>> Subject.  Getting one of those is not always an easy thing, and
>>>>>>> 
>>>>>>> there's a
>>>>>>> 
>>>>>>> lot of value-add in at least putting a stake in the ground as
to how
>>>>>>> 
>>>>>>> one
>>>>>>> 
>>>>>>> obtains a Subject.  Each component library, as an example, could
>>>>>>> 
>>>>>>> provide
>>>>>>> 
>>>>>>> an
>>>>>>> implementation of a provider of Subject material it its own way,
and
>>>>>>> 
>>>>>>> from
>>>>>>> 
>>>>>>> an application point-of-view, one would simply call
>>>>>>> 
>>>>>>> "getCurrentSubject()".
>>>>>>> 
>>>>>>> In my opinion, that's not always an easy thing to get right.
>>>>>>> 
>>>>>>> On Tue, Oct 30, 2012 at 10:22 AM, Guillaume Nodet <gnodet@gmail.com>
>> <
>>>>> gnodet@gmail.com>
>>>>>>> 
>>>>>>> <gnodet@gmail.com> <gnodet@gmail.com>
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Thx for the feedback, Kurt.
>>>>>>> 
>>>>>>> I've looked at Shiro when working on this feature.  Actually,
the
>>>>>>> interface, and even a class I use for the implementation come
from
>>>>>>> 
>>>>>>> shiro.
>>>>>>> 
>>>>>>> The reason why I discarded reusing shiro directly is mainly that
it
>>>>>>> 
>>>>>>> does
>>>>>>> 
>>>>>>> not provide the features we need.  However, that's clearly not
a
>>>>>>> 
>>>>>>> blocking
>>>>>>> 
>>>>>>> point and we could very well reimplement them all on top of shiro,
>>>>>>> 
>>>>>>> mostly
>>>>>>> 
>>>>>>> the realms would not necessarily cover our use cases I think,
or at
>>>>>>> 
>>>>>>> least,
>>>>>>> 
>>>>>>> we'd have to break compatibility completely.  Or maybe another
way to
>>>>>>> integrate would be to implement a jaas realm based on shiro and
>> bridge
>>>>>>> 
>>>>>>> that
>>>>>>> 
>>>>>>> way, not sure if that's really a good idea though.
>>>>>>> 
>>>>>>> However, the exemple you have is clearly on the app level, and
>> there's
>>>>>>> 
>>>>>>> imho
>>>>>>> 
>>>>>>> not a real need to have application security integrated with
the
>>>>>>> 
>>>>>>> container
>>>>>>> 
>>>>>>> security.  If you deploy shiro in a web app, you clearly not
>>>>>>> 
>>>>>>> integrate
>>>>>>> 
>>>>>>> with
>>>>>>> 
>>>>>>> the web container security, so I don't think this is a real problem.
>>>>>>> 
>>>>>>> So
>>>>>>> 
>>>>>>> applications still clearly have the option of deploying shiro
and
>>>>>>> configuring it for their needs.
>>>>>>> 
>>>>>>> I'm happy to discuss that further if people have other opinions.
 The
>>>>>>> 
>>>>>>> above
>>>>>>> 
>>>>>>> just explains why i didn't choose shiro at first and I certainly
>>>>>>> 
>>>>>>> don't
>>>>>>> 
>>>>>>> want
>>>>>>> 
>>>>>>> to reject this option without discussion.
>>>>>>> 
>>>>>>> On Tue, Oct 30, 2012 at 2:49 PM, Kurt Westerfeld<
>>>>>>> 
>>>>>>> kurt.westerfeld@gmail.com> <kurt.westerfeld@gmail.com>
<
>>>>> kurt.westerfeld@gmail.com>wrote:
>>>>>>> 
>>>>>>> I think the problem you find as you go down this route, is not
that
>>>>>>> 
>>>>>>> this
>>>>>>> 
>>>>>>> checkPermission/isPermitted won't work for this command interface,
>>>>>>> 
>>>>>>> but
>>>>>>> 
>>>>>>> that
>>>>>>> 
>>>>>>> there is a more fundamental problem across Karaf-based apps and
>>>>>>> 
>>>>>>> enterprise
>>>>>>> 
>>>>>>> apps in general, in that a javax.security.auth.Subject may actually
>>>>>>> 
>>>>>>> be a
>>>>>>> 
>>>>>>> difficult thing to uniformly provide.  This is because of the
>>>>>>> 
>>>>>>> asynchronous
>>>>>>> 
>>>>>>> nature of Camel/ODE/whatever even within a short-run transaction
in
>>>>>>> 
>>>>>>> an
>>>>>>> 
>>>>>>> ESB,
>>>>>>> 
>>>>>>> and also commonly, the way in which long-running processes can
>>>>>>> hibernate/unhibernate their context/state over time before a
>>>>>>> 
>>>>>>> particular
>>>>>>> 
>>>>>>> service might actually need the Subject information an originating
>>>>>>> 
>>>>>>> caller
>>>>>>> 
>>>>>>> to a service actually had.
>>>>>>> 
>>>>>>> Simplest case:
>>>>>>> - web service call call is authenticated, via basic auth,
>>>>>>> 
>>>>>>> WS-Security,
>>>>>>> 
>>>>>>> whatever
>>>>>>> - web service calls camel
>>>>>>> - camel route implements vm: queue, which blocks caller until
>>>>>>> 
>>>>>>> complete
>>>>>>> 
>>>>>>> - route actually needs Subject, but thread-local context techniques
>>>>>>> don't work here
>>>>>>> 
>>>>>>> Now, perhaps Camel has resolved this (it hadn't a while back),
and
>>>>>>> something like Apache ODE definitely hasn't (you have to manage
this
>>>>>>> 
>>>>>>> stuff
>>>>>>> 
>>>>>>> yourself), but you can see a need here to have something like
>>>>>>> "getSubject()" as a globally-applicable construct in Karaf/ESB
>>>>>>> implementations.
>>>>>>> 
>>>>>>> In one project that combined Java services, Camel services, and
ODE
>>>>>>> services, I had to create a SPI mechanism with OSGi to allow
>> different
>>>>>>> "providers" of javax.security.auth.Subject to have a crack at
>>>>>>> 
>>>>>>> providing
>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> subject for any caller.  In some cases, a thread-local could
suffice,
>>>>>>> 
>>>>>>> and
>>>>>>> 
>>>>>>> in other cases another strategy had to be used (such as stashing
the
>>>>>>> 
>>>>>>> data
>>>>>>> 
>>>>>>> inside a CXF message header, etc).
>>>>>>> 
>>>>>>> As to your interface, I would also add methods such as
>>>>>>> 
>>>>>>> "hasRole(String)"
>>>>>>> 
>>>>>>> because it could be a more convenient way to deal with this.
>>>>>>> 
>>>>>>> Have you looked at Apache Shiro?  I think there's a lot to be
learned
>>>>>>> 
>>>>>>> from
>>>>>>> 
>>>>>>> there, and I've started to use Shiro in some of my projects.
>>>>>>> 
>>>>>>> On Oct 30, 2012, at 7:20 AM, Guillaume Nodet <gnodet@gmail.com>
<
>>>>> gnodet@gmail.com> <
>>>>>>> 
>>>>>>> gnodet@gmail.com>
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I've worked last week on a solution for KARAF-979, i.e. providing
a
>>>>>>> 
>>>>>>> way
>>>>>>> 
>>>>>>> to
>>>>>>> 
>>>>>>> secure shell commands.
>>>>>>> What I came up with is the following.
>>>>>>> 
>>>>>>> A new simple authentication service, exposed as an OSGi service
with
>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> following interface
>>>>>>> 
>>>>>>> public interface AuthorizationService {
>>>>>>> 
>>>>>>> void checkPermission(Subject subject, String permission);
>>>>>>> 
>>>>>>> boolean isPermitted(Subject subject, String permission);
>>>>>>> 
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> This service would be used transparently by karaf commands by
>>>>>>> 
>>>>>>> modifying
>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> BlueprintCommand class and calling checkPermission with the current
>>>>>>> 
>>>>>>> Subject
>>>>>>> 
>>>>>>> and a permission which is
>>>>>>> "command:" + [scope] + ":" + [command]
>>>>>>> 
>>>>>>> Permissions can be set through ConfigAdmin using a single property
>>>>>>> 
>>>>>>> which
>>>>>>> 
>>>>>>> contains an xml which looks like:
>>>>>>> <entries>
>>>>>>>    <entry permission="[xxx]" roles="[xxx]" type="add|set|modify"
>>>>>>> 
>>>>>>> />
>>>>>>> 
>>>>>>>      [ more entries ]
>>>>>>> </entries>
>>>>>>> 
>>>>>>> The matching is done by checking the permission given in the
call to
>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> AuthorizationService with the entries in the configuration.
>>>>>>> 
>>>>>>> Matching
>>>>>>> 
>>>>>>> entries are used to compute the list of authorized roles and
those
>>>>>>> 
>>>>>>> roles
>>>>>>> 
>>>>>>> are checked against the roles of the authenticated Subject.
>>>>>>> This mechanism is the same we had in ServiceMix 3.x.
>>>>>>> 
>>>>>>> This allows to define permissions for a subshell or a single
>>>>>>> 
>>>>>>> command.
>>>>>>> 
>>>>>>> It
>>>>>>> 
>>>>>>> does not provide a very easy way to split read operations from
write
>>>>>>> operations and this would have to be done in an example
>>>>>>> 
>>>>>>> configuration
>>>>>>> 
>>>>>>> maybe
>>>>>>> 
>>>>>>> to ease the user task.
>>>>>>> That said, the mechanism is easily extensible and we can later
add
>>>>>>> permissions for JMX access or any other part of Karaf that would
>>>>>>> 
>>>>>>> benefit
>>>>>>> 
>>>>>>> from that.
>>>>>>> 
>>>>>>> Thoughts welcomed, as usual.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywherehttp://fusesource.com
>>>>>>> 
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywherehttp://fusesource.com
>>>>>>> 
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywherehttp://fusesource.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>> 
>> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com


Mime
View raw message