geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <jbarr...@pivotal.io>
Subject Re: [DISCUSS] authorizing function execution
Date Thu, 17 Aug 2017 20:35:49 GMT
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