+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=1350163 >>> 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.SecurityDefinitionExcep >>>> 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 >> >
