You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Arne Limburg (JIRA)" <ji...@apache.org> on 2012/11/17 22:14:12 UTC
[jira] [Created] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Arne Limburg created DELTASPIKE-292:
---------------------------------------
Summary: @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: Bug
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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Arne Limburg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503430#comment-13503430 ]
Arne Limburg commented on DELTASPIKE-292:
-----------------------------------------
So, Shane, which concrete objections to you have towards checking the parameter bindings at deploy time?
If you don't have any, I would push my solution.
> @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
Re: [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by Arne Limburg <ar...@openknowledge.de>.
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 <st...@yahoo.de>:
>+1 for deployment time t least in ProjectStage Development
>
>+1 for evaluating @Nonbinding
>
>
>
>LieGrue,
>strub
>
>
>
>----- Original Message -----
>> From: Arne Limburg <ar...@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org"
>><de...@incubator.apache.org>
>> 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
>> <ar...@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
>> <ji...@apache.org>:
>>>
>>>>
>>>> [
>>>>
>>>>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
>>>
>>
Re: [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect parameter types of @SecureParameterBinding parameters when determining the authorization method
Posted by Mark Struberg <st...@yahoo.de>.
+1 for deployment time t least in ProjectStage Development
+1 for evaluating @Nonbinding
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> 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
> <ar...@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
> <ji...@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
>>
>
Re: [DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by Arne Limburg <ar...@openknowledge.de>.
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
<ar...@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 <ji...@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
>
[DISCUSS] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by Arne Limburg <ar...@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 <ji...@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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Shane Bryzak (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Shane Bryzak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501784#comment-13501784 ]
Shane Bryzak commented on DELTASPIKE-292:
-----------------------------------------
My apologies, you are correct that it wouldn't be ambiguous (I did't notice that the methods had different parameter types).
> @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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Shane Bryzak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500221#comment-13500221 ]
Shane Bryzak commented on DELTASPIKE-292:
-----------------------------------------
This behaviour is correct, you may only have one authorizer method per security binding type. The parameters for the authorizer method are simply treated as injection points (besides the InvocationContext parameter of course).
> @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: Bug
> 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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Arne Limburg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501752#comment-13501752 ]
Arne Limburg commented on DELTASPIKE-292:
-----------------------------------------
In my scenario there is no ambiguosity since the types of the parameters are different
> @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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Shane Bryzak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504235#comment-13504235 ]
Shane Bryzak commented on DELTASPIKE-292:
-----------------------------------------
While there are some niggling concerns in the back of my mind I can't express them in terms of a real life use case, so I'm happy if we go ahead with the merge.
> @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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Arne Limburg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500249#comment-13500249 ]
Arne Limburg commented on DELTASPIKE-292:
-----------------------------------------
I am talking about @MockParamBinding as a @SecurityParameterBinding type here. And for that I would expect, that only the above @Secures method matches the getBlockedResult method.
> @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: Bug
> 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
[jira] [Commented] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Shane Bryzak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500600#comment-13500600 ]
Shane Bryzak commented on DELTASPIKE-292:
-----------------------------------------
I understand what you're saying, but @SecurityParameterBinding parameters aren't considered in the matching algorithm, only the security binding type itself (in this example @CustomSecurityBinding). See the registerSecuredMethod() method in [1], and matchesBinding() in [2] for the actual code.
[1] https://github.com/DeltaSpike/Mirror/blob/master/deltaspike/modules/security/impl/src/main/java/org/apache/deltaspike/security/impl/extension/SecurityMetaDataStorage.java
[2] https://github.com/DeltaSpike/Mirror/blob/master/deltaspike/modules/security/impl/src/main/java/org/apache/deltaspike/security/impl/extension/Authorizer.java
> @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: Bug
> 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
[jira] [Updated] (DELTASPIKE-292) @SecurityBindings don't respect
parameter types of @SecureParameterBinding parameters when determining the
authorization method
Posted by "Arne Limburg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DELTASPIKE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arne Limburg updated DELTASPIKE-292:
------------------------------------
Issue Type: Improvement (was: Bug)
> @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