geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <ukohlme...@pivotal.io>
Subject Re: [DISCUSS] authorizing function execution
Date Thu, 17 Aug 2017 16:59:08 GMT
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