geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Stewart <jstew...@pivotal.io>
Subject Re: [DISCUSS] authorizing function execution
Date Thu, 17 Aug 2017 20:56:03 GMT
We already have a similar annotation that we use internally to secure GFSH commands: 
@ResourceOperation(resource = Resource.DATA, operation = Operation.MANAGE)
public Result createRegion(
One option might be to move this annotation into a public package and to enforce it if present
on Functions.  The only caveat is that we would need to extend the annotation a bit to support
multiple permissions (right now it only supports a single permission like "DATA:READ", but
not e.g. "DATA:READ and CLUSTER:READ" ). In any case, the permissions required to execute
a function should not change from what they are today unless a function author explicitly
specifies the permissions that should be required.  (Whether in the form of an annotation,
a method, or whatever form we decide on.)

- Jared
> On Aug 17, 2017, at 1:35 PM, Jacob Barrett <jbarrett@pivotal.io> wrote:
> 
> Y'all should checkout PicketLink (now KeyCloak) and how they handle this. I
> used this heavily in the past with JBoss AS. It supports annotation and
> inline restrictions. Also supports EL but that's for another day. While I
> am not advocating today (maybe tomorrow) that we witch to PicketLink but
> looking at other projects that have solved with application server domain
> issue may help us make better choices.
> 
> 
> http://docs.jboss.org/picketlink/2/latest/reference/html/Checking_for_Permissions.html
> 
> 
> On Thu, Aug 17, 2017 at 1:27 PM Udo Kohlmeyer <ukohlmeyer@pivotal.io> wrote:
> 
>> I don't think we should give a user explicit permissions to change the
>> authorization levels for their function.
>> 
>> I think that the SecurityService should have some knowledge about
>> authorization levels on a per-user or per-role. That would check the
>> authorization level on a per-user basis for every function. This might
>> require a more fine grained authorization mechanism to be role-based or
>> more specific user authorization settings should be set up that certain
>> users can only execute specific functions, or not execute functions at
>> all...
>> 
>> In addition to that, there are many functions that could feasibly be
>> read-only. Thus "DATA:READ" permissions would be sufficient... but the
>> current system does not protect itself to access a region and execute a
>> "WRITE" operation, so we are left with the lowest common denominator.
>> 
>> --Udo
>> 
>> 
>> On 8/17/17 12:10, Swapnil Bawaskar wrote:
>>> So, it sounds like if we did #1 above: i.e:
>>> 1) externalize SecurityService so that function author can use it in the
>>> function.execute code to check authorization.
>>> 
>>> we could get this to work with lambdas:
>>> ResultCollector rc = getExecution().execute(context ->
>>>   context.getCache().getSecurityService().authorizeRead();
>>>   // perform read
>>>   context.getResultSender().lastResult(result)
>>> );
>>> 
>>> Udo,
>>> I think there are plenty of use cases where a user would only have
>>> privileges to read data, if this reading of data involves a function,
>> that
>>> user will need write privileges too.
>>> 
>>> On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <ukohlmeyer@pivotal.io>
>>> wrote:
>>> 
>>>> In the case of lambda executions... we have no way to annotate the
>>>> lambda...
>>>> 
>>>> So maybe the "outer" service call needs to help us... Maybe the security
>>>> framework should automatically prevent the execution of any function is
>>>> the user does not have "DATA:READ"/"DATA:WRITE" or "FUNCTION:EXEC"
>>>> privileges.
>>>> 
>>>> In addition to this, do we need to distinguish between "read" and
>>>> "write" functions?
>>>> 
>>>> 
>>>> On 8/17/17 10:43, Dan Smith wrote:
>>>>>> if we get to Lambda-based functions
>>>>> No if about it, this works right now and we do this in our tests :)
>>>>> 
>>>>> ResultCollector rc = getExecution().execute(context ->
>>>>>    context.getResultSender().lastResult("done")
>>>>> );
>>>>> 
>>>>> -Dan
>>>>> 
>>>>> 
>>>>> On Thu, Aug 17, 2017 at 9:59 AM, Udo Kohlmeyer <ukohlmeyer@pivotal.io>
>>>>> wrote:
>>>>> 
>>>>>> I think there might be more to this than just
>> "Data:READ"/"Data:WRITE".
>>>>>> Why would we not support something like
>>>> /*@Authorize(hasRole("functionExecutor"))*/
>>>>>> or /*@Authorize(requiresPermission("DATA:READ"))*/
>>>>>> 
>>>>>> The next question in my mind would be, if we get to Lambda-based
>>>>>> functions, how do we specify authorization credentials then?
>> Annotations
>>>>>> are great to "static" definition on services, not so great for more
>>>>>> "dynamic" execution of stuff...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 8/17/17 09:29, Dan Smith wrote:
>>>>>> 
>>>>>>> I like the annotation idea, especially considering that Jared
was
>>>> talking
>>>>>>> about adding a @RegisterableFunction annotation as well. maybe
>>>> something
>>>>>>> like @ResourcePermission("Data:READ") or something like that?
>>>>>>> 
>>>>>>> -Dan
>>>>>>> 
>>>>>>> On Thu, Aug 17, 2017 at 8:18 AM, Michael William Dodge <
>>>> mdodge@pivotal.io
>>>>>>> wrote:
>>>>>>> 
>>>>>>> What about an annotation for read-only functions or a subinterface
>> off
>>>>>>>> org.apache.geode.cache.execute.Function?
>>>>>>>> 
>>>>>>>> Sarge
>>>>>>>> 
>>>>>>>> On 17 Aug, 2017, at 01:42, Swapnil Bawaskar <sbawaskar@pivotal.io>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Discuss fix for GEODE-2817
>>>>>>>>> <https://issues.apache.org/jira/browse/GEODE-2817>
>>>>>>>>> 
>>>>>>>>> Currently to execute a function, you will need "data:write"
>>>> permission,
>>>>>>>> but
>>>>>>>> 
>>>>>>>>> it really depends on what the function is doing. For
example, if a
>>>>>>>>> 
>>>>>>>> function
>>>>>>>> 
>>>>>>>>> is just reading data, the function author might want
users with
>>>>>>>>> DATA:READ
>>>>>>>>> permissions to execute the function. The two options
mentioned in
>> the
>>>>>>>>> ticket are:
>>>>>>>>> 
>>>>>>>>> 1) externalize SecurityService so that function author
can use it
>> in
>>>> the
>>>>>>>>> function.execute code to check authorization.
>>>>>>>>> 2) add a method to function interface to tell the framework
what
>>>>>>>>> 
>>>>>>>> permission
>>>>>>>> 
>>>>>>>>> this function needs to execute, so that the framework
will check
>> the
>>>>>>>>> permission before executing the function.
>>>>>>>>> 
>>>>>>>>> I vote for #2 because, I think, a function author will
be able to
>>>> easily
>>>>>>>>> discover a method on the Function interface, rather than
trying to
>>>> look
>>>>>>>> for
>>>>>>>> 
>>>>>>>>> SecurityService.
>>>>>>>>> 
>>>>>>>>> I propose that we add the following new method to Function:
>>>>>>>>> 
>>>>>>>>> default public List<ResourcePermission> requiredPermissions()
{
>>>>>>>>>     // default DATA:WRITE
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> In order to preserve existing behavior, the default required
>>>> permission
>>>>>>>>> would be DATA:WRITE.
>>>>>>>>> 
>>>> 
>> 
>> 


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