deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect parameter types of @SecureParameterBinding parameters when determining the authorization method
Date Wed, 21 Nov 2012 08:04:06 GMT
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.ji
>ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501635
>#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.SecurityDefinitionExcept
>>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