Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Jacob Barrett]

So if we don’t want to use the Java built in SecurityManager to solve this, 
because we feel it's too big or too inflexible for our needs, have other 
projects implemented something we can borrow? We can’t be the first to need 
something like this if Java’s solution isn’t a good fit. 

Again I want to avoid inventing something new. What prior art is out there?


> On Jul 4, 2019, at 1:29 PM, Juan José Ramos  wrote:
> 
> Hello all,
> 
> If you haven't added my email to the spam folder already :-), then I'd like
> to let you know that I've update again the *Proposal [1]* and incorporated
> most of the feedback provided, along with some additional information and
> context I missed on the previous versions, thanks all that brought concerns
> and suggestions to the discussion. Please take some time to review it
> thoroughly, adding comments and/or concerns *only on this email thread*,
> all feedback is more than welcome.
> If no major concerns arise before July 12th 2019, I'll go ahead and mark
> move the proposal to *Development* on July 13th.
> Best regards.
> 
> [1]:
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Juan José Ramos]

Hello Jake,

I've replied something similar *here [1]*.
Long story short, I haven't found anything that really applies to our use
case. The "most similar solution" is *Spring Method Security [2]*, which
basically implies annotating methods with explicit configuration about the
roles required to execute them. The same goes for *Shiro **Annotation-based
Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
from the proposal is somewhat similar to this, but I've discarded it
because if forces the user to annotate classes with our own annotations,
basically forcing them to modify their domain model.
The proposal basically allows our users to use one of the default of the
box implementations and, if they don't like them for whatever reason, is
flexible enough so they can ultimately provide their own.
Hope this helps.
Cheers.

[1]:
https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
[2]:
https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
[3]:
https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
[4]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer

On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett  wrote:

> So if we don’t want to use the Java built in SecurityManager to solve
> this, because we feel it's too big or too inflexible for our needs, have
> other projects implemented something we can borrow? We can’t be the first
> to need something like this if Java’s solution isn’t a good fit.
>
> Again I want to avoid inventing something new. What prior art is out there?
>
>
> > On Jul 4, 2019, at 1:29 PM, Juan José Ramos  wrote:
> >
> > Hello all,
> >
> > If you haven't added my email to the spam folder already :-), then I'd
> like
> > to let you know that I've update again the *Proposal [1]* and
> incorporated
> > most of the feedback provided, along with some additional information and
> > context I missed on the previous versions, thanks all that brought
> concerns
> > and suggestions to the discussion. Please take some time to review it
> > thoroughly, adding comments and/or concerns *only on this email thread*,
> > all feedback is more than welcome.
> > If no major concerns arise before July 12th 2019, I'll go ahead and mark
> > move the proposal to *Development* on July 13th.
> > Best regards.
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>
>

-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Jacob Barrett]

Can you please add a Prior Art section to your proposal discussing these 
alternative solutions and why they are insufficient? 

Thanks,
Jake


> On Jul 5, 2019, at 10:41 AM, Juan José Ramos  wrote:
> 
> Hello Jake,
> 
> I've replied something similar *here [1]*.
> Long story short, I haven't found anything that really applies to our use
> case. The "most similar solution" is *Spring Method Security [2]*, which
> basically implies annotating methods with explicit configuration about the
> roles required to execute them. The same goes for *Shiro **Annotation-based
> Authorization [3]*. The *AnnotationBasedMethodAuthorize**r [3]* approach
> from the proposal is somewhat similar to this, but I've discarded it
> because if forces the user to annotate classes with our own annotations,
> basically forcing them to modify their domain model.
> The proposal basically allows our users to use one of the default of the
> box implementations and, if they don't like them for whatever reason, is
> flexible enough so they can ultimately provide their own.
> Hope this helps.
> Cheers.
> 
> [1]:
> https://markmail.org/message/ekons7ixtz4jtf7n#query:+page:1+mid:snxgpsqd3yuppmsc+state:results
> [2]:
> https://docs.spring.io/spring-security/site/docs/5.1.5.RELEASE/reference/html/jc.html#jc-method
> [3]:
> https://shiro.apache.org/authorization.html#Authorization-AnnotationbasedAuthorization
> [4]:
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer
> 
> On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett  wrote:
> 
>> So if we don’t want to use the Java built in SecurityManager to solve
>> this, because we feel it's too big or too inflexible for our needs, have
>> other projects implemented something we can borrow? We can’t be the first
>> to need something like this if Java’s solution isn’t a good fit.
>> 
>> Again I want to avoid inventing something new. What prior art is out there?
>> 
>> 
>>> On Jul 4, 2019, at 1:29 PM, Juan José Ramos  wrote:
>>> 
>>> Hello all,
>>> 
>>> If you haven't added my email to the spam folder already :-), then I'd
>> like
>>> to let you know that I've update again the *Proposal [1]* and
>> incorporated
>>> most of the feedback provided, along with some additional information and
>>> context I missed on the previous versions, thanks all that brought
>> concerns
>>> and suggestions to the discussion. Please take some time to review it
>>> thoroughly, adding comments and/or concerns *only on this email thread*,
>>> all feedback is more than welcome.
>>> If no major concerns arise before July 12th 2019, I'll go ahead and mark
>>> move the proposal to *Development* on July 13th.
>>> Best regards.
>>> 
>>> [1]:
>>> 
>> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
>> 
>> 
> 
> -- 
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
> 
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
>