Re: Securing shell commands

[Guillaume Nodet]

I mostly agree with you, but again, we talk about different things.  I
don't care about security to make sure someone can not shutdown the JVM,
that's code based security, and you're absolutely right, it' best handled
through java security mechanism, with a security manager and the osgi part
can be secured as well with the (Conditional)PermissionAdmin spec.

You're absolutely right saying that the java security model (or the osgi
one) can cover the use case at hand, which is just about role based
authentication for some karaf services.

Now, you raise multiple points.  Most of them I agree with and we can
always improve the api or implementation to cover those (more powerful
permissions, xml in a property file, etc...).
The main point here is about going to the full java security model, where
what we need now is simply an application level security mechanism.
Look at popular containers and you'll see none use a security manager by
default: JBoss, Tomcat, Geronimo, Jetty.  All of them implement application
level security without relying on a security manager (which is, again,
designed for code level security).  Though all of them allow running under
a security manager if the user wants to do so.
I can't think so few people who need application level security don't use
the java security model only because they don't know about it.

I've experimented a bit with the security manager in OSGi.  To have simple
stuff working, I had to fix quite a few problems in the felix
implementation and in blueprint.   The use case was making sure some key
bundles could only be accessed with trusted (signed) bundles.  So that's
not even considering real fine grained security, but that's code level
security, not application level security.  I'd really rather be able to
leverage Shiro, that's why the API has been designed to be easily
implemented and delegate to it when needed.

I think we should separate the two aspects to avoid forcing all users to
run under a security manager.  Supporting such use case is important, some
people may need it (iirc, I haven't heard of it yet though).  Forcing it is
not a good idea imho.

On Mon, Nov 12, 2012 at 10:39 PM, Łukasz Dywicki wrote:

>
> Wiadomość napisana przez Guillaume Nodet w dniu 12 lis 2012, o godz. 21:09:
>
> > On Mon, Nov 12, 2012 at 8:30 PM, Łukasz Dywicki 
> wrote:
> >
> >> 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.
> >>
> >>
> > Karaf uses jaas login modules already, but that's for the authentication
> > part and is kinda unrelated to authorization.
>
> That's true, JAAS is used for authentication. You are talking about
> authorization but proposed solution do not offer even that. Only one thing
> you at this moment which is present is allowing any user execute any
> command. Even with extended configuration it still will be sufficient to
> limit access only to certain commands. In fact it still will be mixin of
> role based access control, where given user or role have access only to
> given set of things. Do we really need another authorization service for
> that? I doubt we not.
> If you want to talk about real authorization then we should be able to
> limit access to specific bundles. To get a proper authorization we must go
> low level and permissions must be an object. Not a string command:list
> because it will fail for sure with commands like start/stop/update which
> have arguments. Do you really want use syntax comand:stop:12 to grant
> privileges? For that you need something mapping file between roles and
> permissions plus subject aware of permissions it holds. Really simple
> example of mapping roles to permissions you can find here
> http://trac.agavi.org/browser/trunk/samples/app/config/rbac_definitions.xml
> .
>
> >> 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 goal isn't really to have this service supported or called by all
> > projects.  Securing the shell commands or the 

Re: Securing shell commands

[Łukasz Dywicki]

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

> On Mon, Nov 12, 2012 at 8:30 PM, Łukasz Dywicki  wrote:
> 
>> 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.
>> 
>> 
> Karaf uses jaas login modules already, but that's for the authentication
> part and is kinda unrelated to authorization.

That's true, JAAS is used for authentication. You are talking about 
authorization but proposed solution do not offer even that. Only one thing you 
at this moment which is present is allowing any user execute any command. Even 
with extended configuration it still will be sufficient to limit access only to 
certain commands. In fact it still will be mixin of role based access control, 
where given user or role have access only to given set of things. Do we really 
need another authorization service for that? I doubt we not.
If you want to talk about real authorization then we should be able to limit 
access to specific bundles. To get a proper authorization we must go low level 
and permissions must be an object. Not a string command:list because it will 
fail for sure with commands like start/stop/update which have arguments. Do you 
really want use syntax comand:stop:12 to grant privileges? For that you need 
something mapping file between roles and permissions plus subject aware of 
permissions it holds. Really simple example of mapping roles to permissions you 
can find here 
http://trac.agavi.org/browser/trunk/samples/app/config/rbac_definitions.xml.

>> 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 goal isn't really to have this service supported or called by all
> projects.  Securing the shell commands or the jmx access isn't related to
> ServiceMix, so that does not really solve the problem at hand.
> The goal isn't to provide a new generic authorization mechanism, the real
> target is karaf own stuff, mainly the shell commands and later JMX services
> and web console.  If it can be opened a bit, that may be a good fit in some
> cases, but again, the main target is not application or messaging security,
> so WS-Security, Camel or ActiveMQ isn't the main target.

I think about security in Karaf in terms of portability to other projects. Do 
you know that you can not use one JAAS realm and re-use it in Karaf 
WebConsole/JMX and ActiveMQ? That's big PITA for users. Introducing another 
service for that will not move as to solution. As said before - we don't need 
the IAuthService to achieve goal you listed.

>> 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.
>> 
>> Login modules configuration is not XML.   PermissionAdmin is really low
> level and mostly for code based security, not application level
> authorization.  I have experimented with the security layer in OSGi, but I
> don't think it's the same use case.
> Have you ever seen a web app using JAAS for authorization ? Really, JAAS
> main use case is code level security. The OSGi security layer is at the
> same level: permissions are define to grant access to some code based on
> the calling bundle, so you can deny calls for given bundles.  But that does
> not fit the use case here.  In the OSGi security layer, the permissions are
> mainly granted based on the code signer, not the JAAS authenticated user,
> so trying to fit in that model is a bad idea imho.
> 
> And again, running in a security manager has a non negligeable overhead to
> running *any* code, so I don't think people will always want to pay that
> cost.

I k

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[j...@nanthrax.net]

We can plan a RC1 middle of next week. I want to fix one issue with subshell.

Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://wwx.talend.com

- Reply message -
From: "Łukasz Dywicki" 
To: 
Subject: [Discuss] Apache Karaf 2.2.10 RC soon?
Date: Mon, Nov 12, 2012 2:32 pm


Gentlemen,
It's time to make man decision. Release Karaf 3 or not!?

We are sitting too long on K3.

Wiadomość napisana przez Jamie G. w dniu 12 lis 2012, o godz. 14:21:

> Karaf 3.0.0.RC1 is very close.
> 
> We can do multiple releases of course - I'm sure everyone would like
> to see 3.0.0.RC1 as well :)
> 
> Cheers,
> Jamie
> 
> On Mon, Nov 12, 2012 at 9:48 AM, Christian Schneider
>  wrote:
>> +1
>> 
>> Btw. what is the status of Karaf 3?
>> I think our build looks really good again. How about doing a RC1?
>> 
>> Christian
>> 
>> On 11/12/2012 01:59 PM, Jamie G. wrote:
>>> Hi All,
>>> 
>>> We've resolved 35 issues on Apache Karaf 2.2.10.
>>> 
>>> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
>>> Any thoughts?
>>> 
>>> Cheers,
>>> Jamie
>> 

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[j...@nanthrax.net]

Hi

We have a couple of issues to investigate around blueprint 0.3 first. I plan to 
work on it tonight (East Coast time).

Regards
JB

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://wwx.talend.com

- Reply message -
From: "Jamie G." 
To: 
Subject: [Discuss] Apache Karaf 2.2.10 RC soon?
Date: Mon, Nov 12, 2012 7:59 am


Hi All,

We've resolved 35 issues on Apache Karaf 2.2.10.

After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
Any thoughts?

Cheers,
Jamie

Re: Securing shell commands

[Guillaume Nodet]

On Mon, Nov 12, 2012 at 8:30 PM, Łukasz Dywicki  wrote:

> 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.
>
>
Karaf uses jaas login modules already, but that's for the authentication
part and is kinda unrelated to authorization.


> 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 goal isn't really to have this service supported or called by all
projects.  Securing the shell commands or the jmx access isn't related to
ServiceMix, so that does not really solve the problem at hand.
The goal isn't to provide a new generic authorization mechanism, the real
target is karaf own stuff, mainly the shell commands and later JMX services
and web console.  If it can be opened a bit, that may be a good fit in some
cases, but again, the main target is not application or messaging security,
so WS-Security, Camel or ActiveMQ isn't the main target.


> 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.
>
> Login modules configuration is not XML.   PermissionAdmin is really low
level and mostly for code based security, not application level
authorization.  I have experimented with the security layer in OSGi, but I
don't think it's the same use case.
Have you ever seen a web app using JAAS for authorization ? Really, JAAS
main use case is code level security. The OSGi security layer is at the
same level: permissions are define to grant access to some code based on
the calling bundle, so you can deny calls for given bundles.  But that does
not fit the use case here.  In the OSGi security layer, the permissions are
mainly granted based on the code signer, not the JAAS authenticated user,
so trying to fit in that model is a bad idea imho.

And again, running in a security manager has a non negligeable overhead to
running *any* code, so I don't think people will always want to pay that
cost.


> 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 
> 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 
> >> 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 t

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[Łukasz Dywicki]

Gentlemen,
It's time to make man decision. Release Karaf 3 or not!?

We are sitting too long on K3.

Wiadomość napisana przez Jamie G. w dniu 12 lis 2012, o godz. 14:21:

> Karaf 3.0.0.RC1 is very close.
> 
> We can do multiple releases of course - I'm sure everyone would like
> to see 3.0.0.RC1 as well :)
> 
> Cheers,
> Jamie
> 
> On Mon, Nov 12, 2012 at 9:48 AM, Christian Schneider
>  wrote:
>> +1
>> 
>> Btw. what is the status of Karaf 3?
>> I think our build looks really good again. How about doing a RC1?
>> 
>> Christian
>> 
>> On 11/12/2012 01:59 PM, Jamie G. wrote:
>>> Hi All,
>>> 
>>> We've resolved 35 issues on Apache Karaf 2.2.10.
>>> 
>>> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
>>> Any thoughts?
>>> 
>>> Cheers,
>>> Jamie
>> 

Re: Securing shell commands

[Łukasz Dywicki]

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  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 
>> 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.westerf...@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.
> 
>>>

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[Andreas Pieber]

I not against a full blown release series including 2.2.10, 2.3.1 and
3.0.0.RC1 ;-)

But, 2.2.10 for a start sounds great to me; +1 for that

Kind regards,
Andreas


On Mon, Nov 12, 2012 at 2:21 PM, Jamie G.  wrote:

> Karaf 3.0.0.RC1 is very close.
>
> We can do multiple releases of course - I'm sure everyone would like
> to see 3.0.0.RC1 as well :)
>
> Cheers,
> Jamie
>
> On Mon, Nov 12, 2012 at 9:48 AM, Christian Schneider
>  wrote:
> > +1
> >
> > Btw. what is the status of Karaf 3?
> > I think our build looks really good again. How about doing a RC1?
> >
> > Christian
> >
> > On 11/12/2012 01:59 PM, Jamie G. wrote:
> >> Hi All,
> >>
> >> We've resolved 35 issues on Apache Karaf 2.2.10.
> >>
> >> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
> >> Any thoughts?
> >>
> >> Cheers,
> >> Jamie
> >
>

Re: Securing shell commands

[Guillaume Nodet]

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  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 
> 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.westerf...@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  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.pozolo...@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  
> > 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.
> >
> > On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin <
> >>> andrei.pozolo...@gmail.com> wrote:
> >
> >
> > I mean why
> >
> > void checkPermission(List principals, String permission);

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[Jamie G.]

Karaf 3.0.0.RC1 is very close.

We can do multiple releases of course - I'm sure everyone would like
to see 3.0.0.RC1 as well :)

Cheers,
Jamie

On Mon, Nov 12, 2012 at 9:48 AM, Christian Schneider
 wrote:
> +1
>
> Btw. what is the status of Karaf 3?
> I think our build looks really good again. How about doing a RC1?
>
> Christian
>
> On 11/12/2012 01:59 PM, Jamie G. wrote:
>> Hi All,
>>
>> We've resolved 35 issues on Apache Karaf 2.2.10.
>>
>> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
>> Any thoughts?
>>
>> Cheers,
>> Jamie
>

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[Christian Schneider]

+1

Btw. what is the status of Karaf 3?
I think our build looks really good again. How about doing a RC1?

Christian

On 11/12/2012 01:59 PM, Jamie G. wrote:
> Hi All,
>
> We've resolved 35 issues on Apache Karaf 2.2.10.
>
> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
> Any thoughts?
>
> Cheers,
> Jamie

Re: [Discuss] Apache Karaf 2.2.10 RC soon?

[Achim Nierbeck]

+1

so let's get on with 2.2.10 and a 2.3.1
so we can focus more on 3.0.0.RC1 to get out of the door ;)

regards, Achim


2012/11/12 Jamie G. 

> Hi All,
>
> We've resolved 35 issues on Apache Karaf 2.2.10.
>
> After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
> Any thoughts?
>
> Cheers,
> Jamie
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

[Discuss] Apache Karaf 2.2.10 RC soon?

[Jamie G.]

Hi All,

We've resolved 35 issues on Apache Karaf 2.2.10.

After karaf-1770 is resolved it may be good to schedule a 2.2.10 RC.
Any thoughts?

Cheers,
Jamie

Re: Securing shell commands

[Łukasz Dywicki]

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  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 >> 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  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.pozolo...@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  
> 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.
> 
> On Wed, Oct 31, 2012 at 12:03 AM, Andrei Pozolotin <
>>> andrei.pozolo...@gmail.com> wrote:
> 
> 
> I mean why
> 
> void checkPermission(List 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  <
>>> bcanh...@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.pozolo...@gm

Issues with Attachments: week of 2012-11-12

[jb]

 
KARAF - Monday, November 12, 2012
 
  11 Issues with Attachments
 
  (sorted oldest to newest)
 
[KARAF-1009] equinox Region support
  (2011-11-12 - Improvement - David Jencks)
  https://issues.apache.org/jira/browse/KARAF-1009
 
[KARAF-1512] enhancement: add self to generated feature in 
"features-generate-descriptor" goal
  (2012-05-30 - New Feature - Benjamin Reed)
  https://issues.apache.org/jira/browse/KARAF-1512
 
[KARAF-1800] Improve documentation EIK Building
  (2012-09-07 - Task - filippo balicchia)
  https://issues.apache.org/jira/browse/KARAF-1800
 
[KARAF-1885] Add src distribution
  (2012-10-02 - Task - Jean-Baptiste Onofré)
  https://issues.apache.org/jira/browse/KARAF-1885
 
[KARAF-1902] Add a friendly option to point karaf-pax-exam to a already 
unpacked directory
  (2012-10-05 - Improvement - Dan Tran)
  https://issues.apache.org/jira/browse/KARAF-1902
 
[KARAF-1922] Upgrade org.apache.aries.jmx.core from 0.3 to 1.0.0
  (2012-10-15 - Task - filippo balicchia)
  https://issues.apache.org/jira/browse/KARAF-1922
 
[KARAF-1925] Blueprint timeout exceptions after karaf startup
  (2012-10-16 - Bug - Xilai Dai)
  https://issues.apache.org/jira/browse/KARAF-1925
 
[KARAF-1947] paxexam-karaf doesn't support to customize test probe
  (2012-10-18 - New Feature - Andreas Pieber)
  https://issues.apache.org/jira/browse/KARAF-1947
 
[KARAF-1950] Eik pde archetype for Camel
  (2012-10-18 - Task - filippo balicchia)
  https://issues.apache.org/jira/browse/KARAF-1950
 
[KARAF-1954] NullPointerException on custom Karaf shell command: 
ClassNotFoundException: org.apache.felix.service.command.Function not found
  (2012-10-19 - Bug - Hendy Irawan)
  https://issues.apache.org/jira/browse/KARAF-1954
 
[KARAF-1968] Uninstalling jndi feature leads to hanging Karaf
  (2012-10-23 - Bug - Zsolt Beothy-Elo)
  https://issues.apache.org/jira/browse/KARAF-1968