karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: Securing shell commands
Date Tue, 30 Oct 2012 17:17:16 GMT
few more concerns/ideas

https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi

-------- Original Message --------
Subject: Securing shell commands
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@karaf.apache.org
Date: Tue 30 Oct 2012 06:20:25 AM CDT
> 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.
>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message