I've updated the gist [1] (see ReadingAuthorizer0) to see how it works out. If we leave out the "on", then it would even read better. You could read the method call like a sentence:
public boolean isAllowedToRead(@SecuredReturn Address a... So +1 for @SecuredReturn from me [1] https://gist.github.com/4279323 Am 15.12.12 21:59 schrieb "Romain Manni-Bucau" unter <[email protected]>: >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 >>>> >> >>> >>>> >> > >>>> >> >>>> >> >>>> >>>> >>
