On 19.08.2013 10:55, David Bosschaert wrote:
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 of *existing* services based on
Principals of the current user.
So I actually agree with Cristian that this would indeed be a nice general
feature. It should be possible to generalize my proposal so that it can be
used for other purposes than just commands...
An extension with Shiro (expecially now that we have Pax Shiro ;)) is a
good idea.
That should be possible later, but I'd like to keep it as simple as
possible for now. There is no need to use Shiro for this stuff, but I can
see that people who already use Shiro like to have an integration.
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 standard approach to establish the
security context. Perhaps we could even allow both and have adapters to
establish one context from another.
On 08/15/2013 10:16 PM, Christian Schneider wrote:
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
permissions with service methods.
A service registry hook could then check that the caller has the
permission before allowing the call. Of course there could be other
additional way of adding this information like the service properties
you mentioned.
I'm not sure I like the annotation approach. One of the things that I would
like to enable is for customers to change the roles associated with
operations/service invocations afterwards, simply because the roles chosen
by the developer may not match up with the roles mappings of all
organizations. With an annotation approach you'd have to modify the code
and recompile it when you want to change them. I prefer to use OSGi
ConfigAdmin for that since it completely decouples this information from
the code and can easily be modified later...
We should also provide a generic way to attach authentication
I think there could be three levels of external configurability:
1. You could use annotations with roles like
@RolesAllowed("admin")
public void deleteUser(...);
2. You could use annotations to store permissions
@RolesAllowed("Userservice.deleteUser")
public void deleteUser(...);
Then the mapping to roles could be done by using groups in the simplest
form. group UserService.deleteUser: admin, ...
3. You could completely externalize the decision. In this case a Policy
Decision Point approach could make sense.
You extract the meta information of a service call, give it to a pdp and
get back an authorization decision.
information to a thread that calls a service. I tought about using
apache shiro for this but I am not sure if it is universal enough.
I don't understand why you need Shiro for this.
Isn't javax.security.auth.Subject.doAs() the standard way to do this?
Probably it is. How does this work internally? Does it also use a thread
local? How does it work if you spawn a new thread using an executor or
similar?
I think we should do some examples to see how it works in practice.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
