Hi Christian,
On 19 August 2013 10:29, Christian Schneider <[email protected]>wrote:
> 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.
Yep, this needs to be standard.
> 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.
I would favor having just option 3. I can see that option 2 provides some
form of indirection, but you still need to modify the service code to add
the annotation in the first place. That might be ok for services that have
their code in the Karaf codebase, but for outside services it would be
pretty much impossible.
I would rather have a clear single way of configuring this so that it's
very clear what the definition is - if a security guy wants to figure out
what roles are needed for options 1 & 2 (s)he needs to have access to the
source to read how the annotation was declared, or otherwise rely on
documentation, which you are never sure is actually in sync with the code.
If we'd opt for a combined annotation+external approach it's still quite
hard to get a full overview of what roles are required to invoke what if
you want to understand that... Hence I would simply go for having just
option 3 and keep everything in one place.
> 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.
>
Re Subject.doAs(). The Subject would be configured via JAAS to contain the
appropriate roles for the current user, as we do today in Karaf (although
you should be able to configure Shiro to provide this info)...
Once you're inside a piece of code that is executed via Subject.doAs()
(which could be in a different thread) you can do:
AccessControlContext acc = AccessController.getContext();
Subject subject = Subject.getSubject(acc);
At this point you can get all the Principals from the subject, e.g. all the
roles:
Set<RolePrincipal> roles = subject.getPrincipals(RolePrincipal.class);
This is all plain standard J2SE code, no library dependencies...
Cheers,
David
