deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject Re: [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect parameter types of @SecureParameterBinding parameters when determining the authorization method
Date Wed, 21 Nov 2012 08:13:17 GMT
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
<arne.limburg@openknowledge.de>:

>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 <jira@apache.org>:
>
>>
>>    [ 
>>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
>


Mime
View raw message