deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Bryzak (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect parameter types of @SecureParameterBinding parameters when determining the authorization method
Date Wed, 21 Nov 2012 01:30:58 GMT

    [ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.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.SecurityDefinitionException:
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