and the secure one too so it is not ambigous +1 for this one Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2012/12/15 Arne Limburg <[email protected]>: > You mean to the second list? > I like that, because it contains the java keyword "return" > With this I would feel comfortable with 1.C > > What do the others think? > > > Am 15.12.12 21:51 schrieb "Gerhard Petracek" unter > <[email protected]>: > >>we could add @SecuredOnReturn to the list. >> >>regards, >>gerhard >> >> >> >>2012/12/15 Arne Limburg <[email protected]> >> >>> I am also not happy with that name. >>> >>> So we have to decide about two annotations >>> 1. The method-level annotation of the authorizer method: >>> A. @Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) >>> B. @Secures and @SecuresResult >>> C. @Secures for both (pre- and post method-invocation authorization, >>> distinguishing by the existence of the parameter-level annotation) >>> 2. The parameter-level annotation of the injected result (something >>>like a >>> qualifier for the result of the business-method invocation) >>> A. @Result >>> B. @SecuredResult >>> C. Other proposals? >>> >>> And we should consider both together, i.e. The word "Result" in the >>> method-level annotation AND the parameter-level annotation looks ugly. >>> >>> Cheers, >>> Arne >>> >>> Am 14.12.12 18:15 schrieb "Gerhard Petracek" unter >>> <[email protected]>: >>> >>> >-1 for @Result (as a name), because the name is too generic. >>> > >>> >regards, >>> >gerhard >>> > >>> > >>> > >>> >2012/12/14 Arne Limburg <[email protected]> >>> > >>> >> Hi all, >>> >> >>> >> >>> >> I have done the coding and we just need to agree on the names of the >>> >> annotations. >>> >> Looking at the gist I have no strong opinion on one of the solutions. >>> >> However I like the @Secures(AFTER_INVOCATION) a little more because >>>of >>> >>to >>> >> things: >>> >> First it is symmetric to @Secures(BEFORE_INVOCATION) and second the >>> >>other >>> >> solution has the word "Result" twice in the declaration: once in the >>> >> method annotation and once in the parameter annotation. >>> >> >>> >> Cheers, >>> >> Arne >>> >> >>> >> Am 13.12.12 21:09 schrieb "Arne Limburg" unter >>> >> <[email protected]>: >>> >> >>> >> >Hi Mark, >>> >> > >>> >> >I have coded a gist to lookup an address from an entityManager (see >>> >>[1]) >>> >> >using the groups suggested by Rudy: >>> >> > >>> >> >group1 (in my case users with role "guest") -> no access at all >>> >> >group2 (in my case the owner of the address) -> has access but only >>>to >>> >>a >>> >> >limited set of result types (access to his addresses) >>> >> >group3 (in my case users with role "admin") -> has access and can >>>see >>> >>all >>> >> >result >>> >> > >>> >> >I have coded the authorizer twice once using >>>@Secures(AFTER_INVOCATION) >>> >> >and once using @SecuresResult. >>> >> >I think it is obvious that we need just one interceptor (for the >>>custom >>> >> >security annotation @Read) >>> >> >and it should be obvious, too, that it makes no sense to annotate >>>one >>> >>of >>> >> >the authorizer methods with both @Secures and @SecuresResult >>> >> > >>> >> >Hope that helps, >>> >> >Arne >>> >> > >>> >> >[1] https://gist.github.com/4279323 >>> >> > >>> >> >Am 13.12.12 19:27 schrieb "Mark Struberg" unter <[email protected]>: >>> >> > >>> >> > >>> >> >>Could be helpful if we gather some samples in a gist? >>> >> >> >>> >> >>It seems that I have a different understanding about it's usage >>>than >>> >>Arne >>> >> >>(which is much more into it). Arnes argument sounded well funded, >>>but >>> >> >>this excesses my knowledge right now. >>> >> >> >>> >> >>It basically boils down to >>> >> >> >>> >> >>1. does it make sense to have both annotations on the same method? >>> >> >>2. will the stuff get handled by the same interceptor? (well, we >>>will >>> >> >>anyway do the @Dependent InterceptorStrategy trick for it I guess, >>>so >>> >>no >>> >> >>real problem) >>> >> >> >>> >> >> >>> >> >>LieGrue, >>> >> >>strub >>> >> >> >>> >> >> >>> >> >> >>> >> >>----- Original Message ----- >>> >> >>> From: Jason Porter <[email protected]> >>> >> >>> To: "[email protected]" >>> >> >>><[email protected]>; Mark Struberg >>> >><[email protected] >>> >> > >>> >> >>> Cc: >>> >> >>> Sent: Thursday, December 13, 2012 6:32 PM >>> >> >>> Subject: Re: [DISCUSS] DELTASPIKE-298 support >>> >>post-method-authorization >>> >> >>> >>> >> >>> +1 to Mark's names >>> >> >>> >>> >> >>> >>> >> >>> On Thu, Dec 13, 2012 at 4:13 AM, Mark Struberg >>><[email protected]> >>> >> >>>wrote: >>> >> >>> >>> >> >>>> >>> >> >>>> >>> >> >>>> what about @Secures and @SecuresResult? >>> >> >>>> >>> >> >>>> These are 2 different inteceptors, right? >>> >> >>>> >>> >> >>>> A method could also have both >>> >> >>>> >>> >> >>>> @Secures and >>> >> >>>> >>> >> >>>> @SecuresResult >>> >> >>>> >>> >> >>>> >>> >> >>>> LieGrue, >>> >> >>>> strub >>> >> >>>> >>> >> >>>> >________________________________ >>> >> >>>> > From: Arne Limburg <[email protected]> >>> >> >>>> >To: "[email protected]" < >>> >> >>>> [email protected]> >>> >> >>>> >Sent: Thursday, December 13, 2012 12:11 PM >>> >> >>>> >Subject: Re: [DISCUSS] DELTASPIKE-298 support >>> >> >>>>post-method-authorization >>> >> >>>> > >>> >> >>>> >OK, >>> >> >>>> > >>> >> >>>> >so I would go with your first suggestion, Romain: >>> >> >>>> > >>> >> >>>> >@Secures(BEFORE_INVOCATION) and @Secures(AFTER_INVOCATION) >>> >> >>>> > >>> >> >>>> >That would leave the readability of the authorizer method and >>> >> >>>> >BEFORE_INVOCATION could be the default, so that it could left >>> >>blank. >>> >> >>>> > >>> >> >>>> > >>> >> >>>> >Of course the extension detects at deployment time the problem >>> >>that >>> >> >>>>a >>> >> >>>> >authorizer method exists with @Secures(BEFORE_INVOCATION) and >>>a >>> >> >>> parameter >>> >> >>>> >annotated with @Result and suggests to use >>> >> >>>>@Secures(AFTER_INVOCATION) >>> >> >>>> > >>> >> >>>> >Wdyt? >>> >> >>>> > >>> >> >>>> >Am 13.12.12 12:03 schrieb "Romain Manni-Bucau" unter >>> >> >>>> ><[email protected]>: >>> >> >>>> > >>> >> >>>> >>if you add the "post" management @Secures will be >>> >> >>> ambiguous (even if >>> >> >>>> >>naturally i understand pre is implicit) so i'd just switch it >>> >> >>>> >> >>> >> >>>> >>if the API is explicit enough to not need doc it is better ;) >>> >> >>>> >> >>> >> >>>> >>Romain Manni-Bucau >>> >> >>>> >>Twitter: @rmannibucau >>> >> >>>> >>Blog: http://rmannibucau.wordpress.com/ >>> >> >>>> >>LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> >> >>>> >>Github: https://github.com/rmannibucau >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> >>2012/12/13 Arne Limburg <[email protected]>: >>> >> >>>> >>> Btw. are we talking about another name for @Secures or for >>> >> >>> @Result? >>> >> >>>> >>> >>> >> >>>> >>> Thinking about @Secures it should not be too confusing >>> >> >>> (talking with >>> >> >>>> >>> myself here ;-) ), since the developer knows, if he needs >>>the >>> >> >>> result >>> >> >>>> for >>> >> >>>> >>> evaluation or not. So either he adds @Result and will know >>> >> >>> that the >>> >> >>>> >>>method >>> >> >>>> >>> needs to be invoked before the authorization. Or he >>> >> >>> doesn't need the >>> >> >>>> >>> result, then the intuitive thing is, that the authorization >>> >> >>> takes place >>> >> >>>> >>> before the business method invocation... >>> >> >>>> >>> >>> >> >>>> >>> Am 13.12.12 11:55 schrieb "Romain Manni-Bucau" unter >>> >> >>>> >>> <[email protected]>: >>> >> >>>> >>> >>> >> >>>> >>>>so i'd go for @PreSecures and @PostSecures, just >>> >> >>> explicit >>> >> >>>> >>>> >>> >> >>>> >>>>but i wouldn't something not symmetrical >>> >> >>>> >>>> >>> >> >>>> >>>>Romain Manni-Bucau >>> >> >>>> >>>>Twitter: @rmannibucau >>> >> >>>> >>>>Blog: http://rmannibucau.wordpress.com/ >>> >> >>>> >>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> >> >>>> >>>>Github: https://github.com/rmannibucau >>> >> >>>> >>>> >>> >> >>>> >>>> >>> >> >>>> >>>> >>> >> >>>> >>>>2012/12/13 Arne Limburg >>> >> >>> <[email protected]>: >>> >> >>>> >>>>> @Secures sounds cool at a first glance, but may it be >>> >> >>> confusing for >>> >> >>>> >>>>>users? >>> >> >>>> >>>>> >>> >> >>>> >>>>> >>> >> >>>> >>>>> And also we should support a mixture of >>> >> >>> @SecurityParameterBindings >>> >> >>>> and >>> >> >>>> >>>>> result, so the annotation should somehow indicate that >>> >> >>> the parameter >>> >> >>>> >>>>>is >>> >> >>>> >>>>> the return value of the method invocation. >>> >> >>>> >>>>> Consider the following example: >>> >> >>>> >>>>> >>> >> >>>> >>>>> @Copy >>> >> >>>> >>>>> public MyObject copy(@Source MyObject source) { >>> >> >>>> >>>>> ... >>> >> >>>> >>>>> } >>> >> >>>> >>>>> >>> >> >>>> >>>>> public class MyCopyAuthorizer { >>> >> >>>> >>>>> >>> >> >>>> >>>>> @Secures @Copy >>> >> >>>> >>>>> public boolean isCopyAllowed(@Source MyObject >>> >> >>> source, >>> >> >>>> >>>>> @SecuredReturnValue MyObject target) { >>> >> >>>> >>>>> ... >>> >> >>>> >>>>> } >>> >> >>>> >>>>> } >>> >> >>>> >>>>> >>> >> >>>> >>>>> where @Copy is a @SecurityBindingType and @Source is a >>> >> >>>> >>>>> @SecurityParameterBinding >>> >> >>>> >>>>> >>> >> >>>> >>>>> Cheers, >>> >> >>>> >>>>> Arne >>> >> >>>> >>>>> >>> >> >>>> >>>>> Am 13.12.12 11:45 schrieb "Romain >>> >> >>> Manni-Bucau" unter >>> >> >>>> >>>>> <[email protected]>: >>> >> >>>> >>>>> >>> >> >>>> >>>>>>Why @Secures is not fine? >>> >> >>>> >>>>>> >>> >> >>>> >>>>>>if the rule is "on parameter" it is a >>> >> >>> post it can be enough. >>> >> >>>> >>>>>> >>> >> >>>> >>>>>>Another solution is @Secure(hook = POST) with a >>> >> >>> default to PRE >>> >> >>>> >>>>>> >>> >> >>>> >>>>>>Romain Manni-Bucau >>> >> >>>> >>>>>>Twitter: @rmannibucau >>> >> >>>> >>>>>>Blog: http://rmannibucau.wordpress.com/ >>> >> >>>> >>>>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> >> >>>> >>>>>>Github: https://github.com/rmannibucau >>> >> >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> >>>> >>>>>>2012/12/13 Arne Limburg >>> >> >>> <[email protected]>: >>> >> >>>> >>>>>>> Feel free to make a suggestion. >>> >> >>>> >>>>>>> What about >>> >> >>>> >>>>>>> >>> >> >>>> >>>>>>> @SecuredResult >>> >> >>>> >>>>>>> or >>> >> >>>> >>>>>>> @SecuredReturnValue >>> >> >>>> >>>>>>> ? >>> >> >>>> >>>>>>> >>> >> >>>> >>>>>>> Am 13.12.12 10:50 schrieb "Gerhard >>> >> >>> Petracek" unter >>> >> >>>> >>>>>>> <[email protected]>: >>> >> >>>> >>>>>>> >>> >> >>>> >>>>>>>>+1, but imo we need a better name for it. >>> >> >>>> >>>>>>>> >>> >> >>>> >>>>>>>>regards, >>> >> >>>> >>>>>>>>gerhard >>> >> >>>> >>>>>>>> >>> >> >>>> >>>>>>>> >>> >> >>>> >>>>>>>> >>> >> >>>> >>>>>>>>2012/12/13 Rudy De Busscher >>> >> >>> <[email protected]> >>> >> >>>> >>>>>>>> >>> >> >>>> >>>>>>>>> All, >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> I had once also such a requirement >>> >> >>> (post-method authorization) >>> >> >>>> >>>>>>>>>where >>> >> >>>> >>>>>>>>>this >>> >> >>>> >>>>>>>>> could be very handy. >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> We kept information about persons >>> >> >>> (name, age, address, medical >>> >> >>>> >>>>>>>>>info, >>> >> >>>> >>>>>>>>>...) >>> >> >>>> >>>>>>>>> but there where some categories. One >>> >> >>> kind of category was linked >>> >> >>>> >>>>>>>>>to >>> >> >>>> >>>>>>>>>the >>> >> >>>> >>>>>>>>> Royals and you needed a special role >>> >> >>> before you could read the >>> >> >>>> >>>>>>>>>information. >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> So we where only able to determine if >>> >> >>> the user was allowed to >>> >> >>>> read >>> >> >>>> >>>>>>>>>the >>> >> >>>> >>>>>>>>> person information after we had read >>> >> >>> it frmo the database and >>> >> >>>> >>>>>>>>>matched >>> >> >>>> >>>>>>>>>the >>> >> >>>> >>>>>>>>> category. >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> So >>> >> >>>> >>>>>>>>> +1 >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> Regards >>> >> >>>> >>>>>>>>> Rudy >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> On 13 December 2012 09:26, Arne >>> >> >>> Limburg >>> >> >>>> >>>>>>>>><[email protected] >>> >> >>>> >>>>>>>>> >wrote: >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>>>> > Hi Jean-Louis, >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > A simple use case is a method >>> >> >>> that creates an object, stores it >>> >> >>>> >>>>>>>>>to >>> >> >>>> >>>>>>>>>the >>> >> >>>> >>>>>>>>> > database and returns it. >>> >> >>>> >>>>>>>>> > You may want to check the object >>> >> >>> to decide if the user is >>> >> >>>> >>>>>>>>>allowed >>> >> >>>> >>>>>>>>>to >>> >> >>>> >>>>>>>>> > create it. With my proposal it is >>> >> >>> as easy as: >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > public class MyObjectRepository { >>> >> >>>> >>>>>>>>> > @Create >>> >> >>>> >>>>>>>>> > public MyObject create() { >>> >> >>>> >>>>>>>>> > ... >>> >> >>>> >>>>>>>>> > } >>> >> >>>> >>>>>>>>> > } >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > public class MyAuthorizer { >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > @Secures @Create >>> >> >>>> >>>>>>>>> > public boolean >>> >> >>> canCreate(@Result MyObject object) { >>> >> >>>> >>>>>>>>> > // security check here >>> >> >>>> >>>>>>>>> > } >>> >> >>>> >>>>>>>>> > } >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > Hope that makes it clear. And >>> >> >>> note that the check may depend on >>> >> >>>> >>>>>>>>>the >>> >> >>>> >>>>>>>>>state >>> >> >>>> >>>>>>>>> > of the object, i.e. the user is >>> >> >>> just allowed to create the >>> >> >>>> >>>>>>>>>object, >>> >> >>>> >>>>>>>>>if >>> >> >>>> >>>>>>>>>he >>> >> >>>> >>>>>>>>> > is the owner... >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > Cheers, >>> >> >>>> >>>>>>>>> > Arne >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > Am 13.12.12 09:20 schrieb >>> >> >>> "Jean-Louis MONTEIRO" unter < >>> >> >>>> >>>>>>>>> [email protected] >>> >> >>>> >>>>>>>>> > >: >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > >Hi Arne, >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > >Just read the JIRA but could >>> >> >>> not find a relevant use case for >>> >> >>>> >>>>>>>>>that. >>> >> >>>> >>>>>>>>> > >But if you proposed it, I >>> >> >>> probably missed something so if you >>> >> >>>> >>>>>>>>>could >>> >> >>>> >>>>>>>>> > >elaborate a bit more. >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > >Jean-Louis >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > >2012/12/13 Mark Struberg >>> >> >>> <[email protected]> >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> +1 >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> >>> >> >>> ------------------------------ >>> >> >>>> >>>>>>>>> > >> Arne Limburg schrieb am >>> >> >>> Mi., 12. Dez 2012 23:38 PST: >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> >Hi, >>> >> >>>> >>>>>>>>> > >> > >>> >> >>>> >>>>>>>>> > >> >What do you think of >>> >> >>> supporting post-method-authorization >>> >> >>>> >>>>>>>>>(see >>> >> >>>> >>>>>>>>>[1]) >>> >> >>>> >>>>>>>>> in >>> >> >>>> >>>>>>>>> > >> addition to our current >>> >> >>> pre-method-authorization? >>> >> >>>> >>>>>>>>> > >> >I just started >>> >> >>> coding it and it is not much to do. >>> >> >>>> >>>>>>>>> > >> > >>> >> >>>> >>>>>>>>> > >> >Cheers, >>> >> >>>> >>>>>>>>> > >> >Arne >>> >> >>>> >>>>>>>>> > >> > >>> >> >>>> >>>>>>>>> > >> >[1] >>> >> >>> https://issues.apache.org/jira/browse/DELTASPIKE-298 >>> >> >>>> >>>>>>>>> > >> > >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > >> >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > > >>> >> >>>> >>>>>>>>> > >-- >>> >> >>>> >>>>>>>>> > >Jean-Louis >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> > >>> >> >>>> >>>>>>>>> >>> >> >>>> >>>>>>> >>> >> >>>> >>>>> >>> >> >>>> >>> >>> >> >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> Jason Porter >>> >> >>> http://lightguard-jp.blogspot.com >>> >> >>> http://twitter.com/lightguardjp >>> >> >>> >>> >> >>> Software Engineer >>> >> >>> Open Source Advocate >>> >> >>> >>> >> >>> PGP key id: 926CCFF5 >>> >> >>> PGP key available at: keyserver.net, pgp.mit.edu >>> >> >>> >>> >> > >>> >> >>> >> >>> >>> >
