Thanks again JB for reviewing and applying the commits.
I have written a blog article about how it all works here:
http://coderthoughts.blogspot.com/2013/10/role-based-access-control-for-karaf.html
Best regards,
David
On 8 October 2013 16:50, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi all,
I have the pull request for KARAF-2455 (role-based security for OSGi
Services) and KARAF-2442 (role-based security for Karaf Shell
Commands) ready.
Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for
suggesting this originally) I included both in a single pull requests
as
Awesome, thanks a lot David. I will review it tomorrow morning.
Regards
JB
On 10/08/2013 05:44 PM, David Bosschaert wrote:
Hi all,
I have the pull request for KARAF-2455 (role-based security for OSGi
Services) and KARAF-2442 (role-based security for Karaf Shell
Commands) ready.
Since
Hi all,
Just a little status update on this...
I have since implemented most of KARAF-2455 (role-based security for OSGi
Services) and KARAF-2442 (role-based security for Karaf Shell Commands).
They build on top of what I did for KARAF-2434 and KARAF-2435. Once those
are merge I can rebase my
Hi David,
awesome, thanks for the update. I just started to review the patches. I
will apply tonight or tomorrow.
Thanks again,
Regards
JB
On 09/19/2013 11:56 AM, David Bosschaert wrote:
Hi all,
Just a little status update on this...
I have since implemented most of KARAF-2455 (role-based
Since I think the general consensus here is that it would be good to have a
general security mechanism for OSGi services I have created a JIRA for that
(KARAF-2455) and noted that role-based security for the commands can be
built on top of this (KARAF-2442).
Cheers,
David
Hi Christian,
On 22 August 2013 23:14, Christian Schneider ch...@die-schneider.netwrote:
Sounds great. I have not yet looked into it in detail but the concept
sounds decent.
One thing you should keep in mind is to make the authorization
exchangeable. For example at Talend we provide an
Hi guys,
@David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean
registration. Aries JMX looks up for MBeans exposed as OSGi services. So
I think we can leverage it.
WDYT ?
Regards
JB
On 08/23/2013 10:41 AM, David Bosschaert wrote:
Hi Christian,
On 22 August 2013 23:14,
That may be true for the Karaf MBeans but there are also other MBeans in
the system. For example ones provided by the JVM. As an example take the
MBean with the following object name: connector:name=rmi
It is registered by the JVM and not through OSGi services and has a few
operations (start(),
Good point David.
Regards
JB
On 08/23/2013 01:00 PM, David Bosschaert wrote:
That may be true for the Karaf MBeans but there are also other MBeans in
the system. For example ones provided by the JVM. As an example take the
MBean with the following object name: connector:name=rmi
It is
Hi all,
As suggested by Christian, I started looking at adding role-based access to
OSGi services in general (in Karaf) and applying this to the Karaf commands.
At this point I have something that kinda works. It proxies services for
service consumers using service registry hooks and on
Hi David,
again it sounds good, and it's what I had in mind.
Before provide a more complete feedback, let me take a look on your github.
Thanks anyway !
Regards
JB
On 08/22/2013 05:07 PM, David Bosschaert wrote:
Hi all,
As suggested by Christian, I started looking at adding role-based
Yeah, but it gives good indication about what you want to do ;)
Cheers
JB
On 08/22/2013 07:47 PM, David Bosschaert wrote:
Thanks JB,
Don't take the code on my github commit too literally ;) I'm more wondering
whether people like the approach in general. As I said, the code itself is
quite
Sounds great. I have not yet looked into it in detail but the concept
sounds decent.
One thing you should keep in mind is to make the authorization
exchangeable. For example at Talend we provide an xacml based pdp. So it
would be great to have a hook wehere we can plug this in to
do the auth
Hi all,
On 15 August 2013 21:23, Jean-Baptiste Onofré j...@nanthrax.net wrote:
OSGi already provides the security module for that, and it's what David
proposed (to leverage the services security).
Well AFAIK OSGi doesn't yet contain a general framework for
allowing/disallowing the invocation
Hi Christian,
On 19 August 2013 10:29, Christian Schneider ch...@die-schneider.netwrote:
The idea was to use Shiro to establish a kind of security context in a
thread local. Your approach of using Subject.doas might be the better
alternative though.
In any case we should recommend one
Hi all,
In the context of KARAF-2442 I started looking at securing the commands in
the shell. I wanted to do something similar to what I did for the JMX
access (KARAF-2435) in that this should be configurable by a Karaf
administrator. I also really wanted a generic solution that would work with
Hi David,
Your proposal looks good. I would just add a couple of other features,
like command scope management (used for the sub-shell on trunk especially).
I have your patch/pull request on my machine. I gonna review it and get
back to you.
Thanks !
Regards
JB
On 08/15/2013 04:26 PM,
I like the idea of adding permissions to the commands. I wonder though
if this is perhaps a more general problem that not only affects commands.
So how about adding a generic permission check for services? For example
I would like to use the @RolesAllowed annotation to couple roles or
OSGi already provides the security module for that, and it's what David
proposed (to leverage the services security).
An extension with Shiro (expecially now that we have Pax Shiro ;)) is a
good idea.
Regards
JB
On 08/15/2013 10:16 PM, Christian Schneider wrote:
I like the idea of adding
+1 for this proposal.
I like the idea that we needn't change current commands code, but hack it
through service registry hooks.
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog:
21 matches
Mail list logo
