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