Hi Mark,
@Nonbinding is currently supported for @SecurityBindingType @SecurityParameterBinding does completely ignore values, which we should change, too, imho Cheers, Arne Am 21.11.12 11:05 schrieb "Mark Struberg" unter <[email protected]>: >+1 for deployment time t least in ProjectStage Development > >+1 for evaluating @Nonbinding > > > >LieGrue, >strub > > > >----- Original Message ----- >> From: Arne Limburg <[email protected]> >> To: "[email protected]" >><[email protected]> >> Cc: >> Sent: Wednesday, November 21, 2012 9:13 AM >> Subject: Re: [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect >>parameter types of @SecureParameterBinding parameters when determining >>the authorization method >> >> So, to make it short: >> >> We should detect ambiguities at DEPLOYMENT time (instead of ignoring >>them >> and throwing exceptions at RUNTIME) and either >> 1. reject them or >> 2. resolve them by taking into account the types of the parameters and >>the >> @SecurityParameterBindings >> >> +1 for 2. since that is the smarter solution >> >> Cheers, >> Arne >> >> Am 21.11.12 09:04 schrieb "Arne Limburg" unter >> <[email protected]>: >> >>> Hi Shane, >>> >>> Hi all, >>> >>> We should move this discussion over to the list to get more opinions. >>> The current implementation of our @SecurityBindingType in combination >>>with >>> @SecurityParameterBinding has some unexpected behavior: >>> Consider the following scenario: >>> >>> public class MyRepositoy { >>> @CRUD >>> public void persist(@Create MyObject1 obj) { >>> Š >>> } >>> } >>> >>> public class MyCrudAuthorizer { >>> >>> @Secures @CRUD >>> public boolean canCreate(@Create MyObject1 obj) { >>> return Š >>> } >>> >>> @Secures @CRUD >>> public boolean canCreate(@Create MyObject2 obj) { >>> return Š >>> } >>> } >>> >>> With the current implementation this would lead to a DEPLOYMENT error, >>> because the binding for @CRUD is ambiguous. I would not have expected >>> this, since it is obvious which authorizer method should be taken. >>> >>> And even worse, if I remove the method >>> >>> public boolean canCreate(@Create MyObject1 obj) >>> >>> this leads to a ClassCastException at RUNTIME since the type of the >>> parameter is never checked. >>> If I remove the @Create annotation from the persist method it leads to >>>an >>> IllegalStateException at RUNTIME, because the Authorizer needs this >>> parameter. >>> >>> We definitely need more checks at DEPLOYMENT time here. And if we do >>>so, >>> we should consider taking the @SecurityParameterBinding types into >>>account >>> when resolving the authorizers. >>> >>> What do the others think? >>> >>> Cheers, >>> Arne >>> >>> P.S.: I have nearly completed a solution that takes the parameter >>>bindings >>> into account. If you want, I can push it into master or into a branch >>>for >>> review. >>> >>> Am 21.11.12 02:30 schrieb "Shane Bryzak (JIRA)" unter >> <[email protected]>: >>> >>>> >>>> [ >>>> >>>>https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian >>>>.j >>>> i >>>> >>>>ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501 >>>>63 >>>> 5 >>>> #comment-13501635 ] >>>> >>>> Shane Bryzak commented on DELTASPIKE-292: >>>> ----------------------------------------- >>>> >>>> I'm not so sure that is a good idea. It was never the intent to >> include >>>> the @SecurityParameterBinding parameters in the matching algorithm, >>>>and >>>> there may be detrimental side effects of doing so. The entire >>>> @SecurityParameterBinding mechanism is simply intended as a means to >> pass >>>> state from the method invocation to the authorizer method, and >>>>matching >>>> should only be done on the @SecurityBindingType annotation(s) itself. >>>> Also, in the use case that you presented above, there would still be >>>>an >>>> ambiguous resolution as the InvocationContext is an optional injection >>>> point for the authorizer method, so both methods will still match. My >>>> suggestion is to simply use the @SecurityBindingType mechanism as it >>>>was >>>> intended, and simply provide either a) an additional member value to >> bind >>>> with, or b) a unique combination of @SecurityBindingType annotations. >>>> For an example of a), the following code will work: >>>> >>>> @ApplicationScoped >>>> public class SecuredBean >>>> { >>>> @CustomSecurityBinding(value = 1) >>>> public boolean getBlockedResult(@MockParamBinding MockObject >>>> mockObject) >>>> { >>>> return mockObject.isValue(); >>>> } >>>> >>>> public boolean getResult(MockObject mockObject) >>>> { >>>> return mockObject.isValue(); >>>> } >>>> } >>>> >>>> @ApplicationScoped >>>> public class CustomAuthorizer >>>> { >>>> @Secures >>>> @CustomSecurityBinding(value = 1) >>>> public boolean doSecuredCheck(@MockParamBinding MockObject obj, >>>> InvocationContext invocationContext) >>>> throws Exception >>>> { >>>> return obj.isValue(); >>>> } >>>> >>>> @Secures >>>> @CustomSecurityBinding(value = 2) >>>> public boolean doSecuredCheck(@MockParamBinding MockObject2 obj) >>>> { >>>> return obj.isValue(); >>>> } >>>> } >>>> >>>> This example is a little contrived (you wouldn't use an int value) >>>> however it demonstrates the point. >>>> >>>>> @SecurityBindings don't respect parameter types of >>>>> @SecureParameterBinding parameters when determining the >> authorization >>>>> method >>>>> >>>>> >>>>>---------------------------------------------------------------------- >>>>>-- >>>>> - >>>>> ------------------------------------------------------ >>>>> >>>>> Key: DELTASPIKE-292 >>>>> URL: >>>>> https://issues.apache.org/jira/browse/DELTASPIKE-292 >>>>> Project: DeltaSpike >>>>> Issue Type: Improvement >>>>> Components: Security-Module >>>>> Affects Versions: 0.3-incubating >>>>> Reporter: Arne Limburg >>>>> Assignee: Arne Limburg >>>>> >>>>> The following beans lead to the following exception: >>>>> >>>>>org.apache.deltaspike.security.api.authorization.SecurityDefinitionExc >>>>>ep >>>>> t >>>>> ion: Ambiguous authorizers found for security binding type >>>>> @ApplicationScoped >>>>> public class SecuredBean >>>>> { >>>>> @CustomSecurityBinding >>>>> public boolean getBlockedResult(@MockParamBinding MockObject >>>>> mockObject) >>>>> { >>>>> return mockObject.isValue(); >>>>> } >>>>> public boolean getResult(MockObject mockObject) >>>>> { >>>>> return mockObject.isValue(); >>>>> } >>>>> } >>>>> @ApplicationScoped >>>>> public class CustomAuthorizer >>>>> { >>>>> @Secures >>>>> @CustomSecurityBinding >>>>> public boolean doSecuredCheck(@MockParamBinding MockObject obj, >>>>> InvocationContext invocationContext) >>>>> throws Exception >>>>> { >>>>> return obj.isValue(); >>>>> } >>>>> >>>>> @Secures >>>>> @CustomSecurityBinding >>>>> public boolean doSecuredCheck(@MockParamBinding MockObject2 >> obj) >>>>> { >>>>> return obj.isValue(); >>>>> } >>>>> } >>>> >>>> -- >>>> This message is automatically generated by JIRA. >>>> If you think it was sent incorrectly, please contact your JIRA >>>> administrators >>>> For more information on JIRA, see: >> http://www.atlassian.com/software/jira >>> >>
