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 <[email protected]> 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 <
> [email protected]> 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 <[email protected]> <[email protected]>
>> To: [email protected]
>> 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
>> <[email protected]> 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 <[email protected]> <[email protected]>
>> To: [email protected]
>> 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 <[email protected]>
>> <[email protected]>:
>>
>> 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 <[email protected]> <[email protected]>
>> To: [email protected]
>> 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
>> <[email protected]> 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 <[email protected]> <[email protected]>
>> <[email protected]> <[email protected]>
>> To: [email protected], [email protected]
>> 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 <[email protected]>
>> <[email protected]> <
>>
>> [email protected]> 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 <
>>
>> [email protected]> 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 <[email protected]>
>> <[email protected]>
>>
>> <[email protected]> <[email protected]>
>>
>> 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<
>>
>> [email protected]> <[email protected]>
>> <[email protected]>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 <[email protected]>
>> <[email protected]> <
>>
>> [email protected]>
>>
>> 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
