Re: [DISCUSS] authorizing function execution

Yeah that's the right level of authorization. The Function Author should get to decide. Listeners, Loaders and Writers should only require DATA:READ and DATA:WRITE as appropriate. It is up to the authors what they do inside of those. -- Mike Stolz Principal Engineer, GemFire Product Manager

Re: [DISCUSS] authorizing function execution

Indeed, the function author has a higher level of privilege than someone who is invoking a function, that is why the proposal here is to let the function author choose what level of permissions are required to invoke a function. On Thu, Sep 14, 2017 at 11:20 AM Anilkumar Gingade

Re: [DISCUSS] authorizing function execution

>> from reaching into internal classes If thats the case; one could do anything, even with read permission...Isn't it... On Thu, Sep 14, 2017 at 10:43 AM, Jared Stewart wrote: > There is nothing to prevent code in a function that's executing on a > server from reaching

Re: [DISCUSS] authorizing function execution

There is nothing to prevent code in a function that's executing on a server from reaching into internal classes and bypassing the public region APIs. I think a function's author should ultimately determine the permissions required to execute it. > On Sep 14, 2017, at 10:34 AM, Anilkumar

Re: [DISCUSS] authorizing function execution

When a function is accessing/modifying region; the function will be doing so by region apis, don't we have credential check with region apis; if not can we add those checks here...instead of having it in the function... -Anil. On Wed, Sep 13, 2017 at 11:22 AM, Jared Stewart

Re: [DISCUSS] authorizing function execution

After some more investigation into the implementation details, here is our updated proposal to add to the Function interface: default Collection getRequiredPermissions(Optional onRegion) { return Collections.singletonList(ResourcePermissions.DATA_WRITE); } This method can be overridden by

Re: [DISCUSS] authorizing function execution

When we speak of "users" here, do we mean normal developers or "administrational users"? My concern is that given the current functionality of "deploy jar" it would be too easy to deploy a jar, containing a function that has "relaxed" user permissions. Which would allow them to execute ANY

Re: [DISCUSS] authorizing function execution

> On Aug 17, 2017, at 1:41 PM, Dan Smith wrote: > > Which means > the develop needs a way override the permission level *before* the function > executes. I agree. Providing a callback to allow a user to override the default security level seems reasonable. Anthony

Re: [DISCUSS] authorizing function execution

I like the simplicity of the annotation, but that simplicity has some problems other than just playing nicely with lambdas. If permission required is dependent on function parameters or cluster state, it can't (currently) be resolved as part of the annotation. We already work-around this in a

Re: [DISCUSS] authorizing function execution

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

Re: [DISCUSS] authorizing function execution

On Thu, Aug 17, 2017 at 12:10 PM, 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: >

Re: [DISCUSS] authorizing function execution

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

Re: [DISCUSS] authorizing function execution

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

Re: [DISCUSS] authorizing function execution

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

Re: [DISCUSS] authorizing function execution

Is there a requirement of, changing the permission in future time...E.g. Currently the function has WRITE permission, but needs to be changed to READ, without re-writing/deploying the function. In that case, permissions needs to be independent of function implementation. -Anil. On Thu, Aug 17,

Re: [DISCUSS] authorizing function execution

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"

Re: [DISCUSS] authorizing function execution

> 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 wrote:

Re: [DISCUSS] authorizing function execution

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

Re: [DISCUSS] authorizing function execution

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 wrote:

Re: [DISCUSS] authorizing function execution

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 wrote: > > Discuss fix for GEODE-2817 > > > Currently

[DISCUSS] authorizing function execution

Discuss fix for 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