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