You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dmitry Gusev <dm...@gmail.com> on 2012/10/11 15:38:26 UTC
Tynamo tapestry-security Instance-Level Access Control?
Hi,
I need to implement instance-level access control in my application using
tapestry-security.
I already asked similar question here [1].
There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
tapestry-security.
I looked at Entity-Relationship Based Access Control [2].
This is not exactly what I need, because I don't even have DAO layer
involved here.
Here's what I have. I have business method in one of my services:
@RequiresPermissions("task:submit")
void submitTask(Task newTask);
I read about ILAC on Shiro's web site [2].
This looks similar, but in my domain not every user may submit every task
for execution.
I have custom logic that should inspect instance of the newTask and decide
whether current user has permissions to submit the task for execution or
not.
In Shiro's documentation [3] there's a note that tells that a developer may
write its own implementation of AuthorizingRealm.isPermitted(*) to check
permissions against custom domain model. I'm not sure about this in my
case, though, because this note is given in 'Performance Considerations'
section.
One more thing that stops me from overriding AuthorizingRealm.isPermitted(*) is
I don't have access to invocation context, i.e. I can't get instance of the
newTask from example above:
AuthorizingRealm realm = new AuthorizingRealm()
{
@Override
public boolean isPermitted(PrincipalCollection principals,
Permission permission) {
// XXX ... can't access to newTask instance
}
I was thinking about fixing Tynamo's SecurityInterceptor advise, by putting
MethodInvocation into Tapestry Environment service instance and getting
this MethodInvocation from there in realm.
Am I in the right direction? Any suggestions?
[1]
http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
[2] http://tynamo.org/tapestry-security-jpa+guide
[3]
http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
[4]
http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Dmitry Gusev <dm...@gmail.com>.
Thanks, Kalle!
I've attached another patch to the same issue that does the same thing for
component method interceptors.
FYI:
Here's how my implementation of ILAC looks like.
I implemented abstraction layer of permission controllers that allows:
- automatically pick right controller by permission domain. For
instance, ProjectPermissionController will be used to check permissions for
"project:view:1" (see below)
- extract target instance key/id from permission, if permission is in
the form of "domain:action:target" and perform lookup by this key
This may be helpful if you do permission check from code like this:
securityService.hasPermission("project:" + permissionAction + ":" + project
.getId());
- extract target instance from intercepted method argument. Controller
may use object instance from parameter as-is if available:
@RequiresPermissions(PermissionConstants.PROJECT_EDIT_CORRECTIONS)
@CommitAfter
Resolution updateResolution(Project project, String word, Resolution
resolution);
- ... or get instance key/id from parameters and perform instance lookup
by this key:
@RequiresPermissions(PermissionConstants.TASK_CANCEL)
void cancelTask(int taskId);
Permission controllers may be contributed in AppModule:
@Contribute(ILACAuthorizingRealm.class)
public static
voidaddPermissionControllers(OrderedConfiguration<PermissionController>
conf)
{
conf.addInstance("project", ProjectPermissionController.class);
}
Example of PermissionController:
public class ProjectPermissionController
extendsAbstractILACPermissionController<Integer, Project>
{
private final ProjectManager projectManager;
public ProjectPermissionController(Environment environment,
TypeCoercer coercer,
ProjectManager projectManager)
{
super(environment, coercer, "project:*");
this.projectManager = projectManager;
}
@Override
public boolean isPermitted(PrincipalCollection principals,
ILACPermission permission,
Project project)
{
if (project == null)
{
// Project not found == Access forbidden
return false;
}
// TODO Check ACL for the project
return true;
}
@Override
protected Class<Project> getInstanceClass()
{
return Project.class;
}
@Override
protected Class<Integer> getInstanceKeyClass()
{
return int.class;
}
@Override
protected Project lookupInstanceByKey(Integer key)
{
return projectManager.findById(key);
}
}
On Fri, Oct 12, 2012 at 11:39 AM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:
> Applied, excellent patch thanks!
>
> Kalle
>
> On Thu, Oct 11, 2012 at 3:35 PM, Dmitry Gusev <dm...@gmail.com>
> wrote:
> > Done:
> >
> > http://jira.codehaus.org/browse/TYNAMO-183
> >
> >
> > On Fri, Oct 12, 2012 at 1:46 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
> >
> >> Using @Core annotation helped:
> >>
> >> @Match("*")
> >>
> >> @Order("before:*")
> >>
> >> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
> >>
> >> final @Core Environment environment)
> >>
> >>
> >> On Fri, Oct 12, 2012 at 12:59 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
> >>
> >>> Ok, I'm working on the patch now.
> >>>
> >>> I have a problem injecting Environment instance into advisor method in
> >>> SecurityModule:
> >>>
> >>> @Match("*")
> >>>
> >>> @Order("before:*")
> >>>
> >>> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
> >>>
> >>> final Environment environment)
> >>>
> >>> this issue was already filed in JIRA:
> >>>
> >>> https://issues.apache.org/jira/browse/TAP5-1045
> >>>
> >>>
> >>> Caused by: java.lang.IllegalStateException: Construction of service
> >>> 'AssetObjectProvider' has failed due to recursion: the service depends
> on
> >>> itself in some way. Please check
> >>> org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource,
> >>> TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via
> >>> org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at
> >>> TapestryModule.java:308) for references to another service that is
> itself
> >>> dependent on service 'AssetObjectProvider'.
> >>>
> >>> at
> >>>
> org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(
> >>> RecursiveServiceCreationCheckWrapper.java:52)
> >>>
> >>>
> >>>
> >>> On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen <
> >>> kalle.o.korhonen@gmail.com> wrote:
> >>>
> >>>> Instance-level access control is a very interesting topic to me. I say
> >>>> you are pretty much on the right track if you want to use the
> >>>> permission model. You wouldn't *necessarily* need to change anything
> >>>> in Shiro if you just did programmatic checks with isPermitted and you
> >>>> knew the right permissions at the time you are creating the
> >>>> AuthorizationInfo. However, that model is cumbersome as you need to
> >>>> create all the permissions upfront and then later formulate specific
> >>>> ones when doing an authorization check - and you still couldn't use
> >>>> annotations. Alex' syntax is one way to go about and you certainly
> >>>> need some property substitution syntax for doing instance level checks
> >>>> with annotations. Using the environment for fetching the
> >>>> MethodInvocation sounds reasonable and I'm open to adding that as a
> >>>> patch to tapestry-security. That way everybody at least wouldn't need
> >>>> to introduce their own annotations.
> >>>>
> >>>> Entity-Relationship Based Access control is a completely different
> >>>> take on the same topic. It's based on the idea that the data objects
> >>>> you are trying to secure are in one way or another associated to the
> >>>> currently executing subject. It greatly simplifies the syntax required
> >>>> but obviously limits the possibilities as well. You wouldn't
> >>>> necessarily need a "DAO" but still, some single, uniformed way of
> >>>> accessing the data objects. The current implementation works at the
> >>>> (JPA) EntityManager level.
> >>>>
> >>>> Kalle
> >>>>
> >>>>
> >>>> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >
> >>>> wrote:
> >>>> > Hi,
> >>>> >
> >>>> > I need to implement instance-level access control in my application
> >>>> using
> >>>> > tapestry-security.
> >>>> >
> >>>> > I already asked similar question here [1].
> >>>> >
> >>>> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
> >>>> > tapestry-security.
> >>>> >
> >>>> > I looked at Entity-Relationship Based Access Control [2].
> >>>> >
> >>>> > This is not exactly what I need, because I don't even have DAO layer
> >>>> > involved here.
> >>>> >
> >>>> > Here's what I have. I have business method in one of my services:
> >>>> >
> >>>> > @RequiresPermissions("task:submit")
> >>>> >
> >>>> > void submitTask(Task newTask);
> >>>> >
> >>>> > I read about ILAC on Shiro's web site [2].
> >>>> >
> >>>> > This looks similar, but in my domain not every user may submit every
> >>>> task
> >>>> > for execution.
> >>>> > I have custom logic that should inspect instance of the newTask and
> >>>> decide
> >>>> > whether current user has permissions to submit the task for
> execution
> >>>> or
> >>>> > not.
> >>>> >
> >>>> > In Shiro's documentation [3] there's a note that tells that a
> >>>> developer may
> >>>> > write its own implementation of AuthorizingRealm.isPermitted(*) to
> >>>> check
> >>>> > permissions against custom domain model. I'm not sure about this in
> my
> >>>> > case, though, because this note is given in 'Performance
> >>>> Considerations'
> >>>> > section.
> >>>> >
> >>>> > One more thing that stops me from overriding
> >>>> AuthorizingRealm.isPermitted(*) is
> >>>> > I don't have access to invocation context, i.e. I can't get instance
> >>>> of the
> >>>> > newTask from example above:
> >>>> >
> >>>> > AuthorizingRealm realm = new AuthorizingRealm()
> >>>> >
> >>>> > {
> >>>> >
> >>>> > @Override
> >>>> >
> >>>> > public boolean isPermitted(PrincipalCollection
> principals,
> >>>> > Permission permission) {
> >>>> >
> >>>> > // XXX ... can't access to newTask instance
> >>>> >
> >>>> > }
> >>>> >
> >>>> >
> >>>> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by
> >>>> putting
> >>>> > MethodInvocation into Tapestry Environment service instance and
> getting
> >>>> > this MethodInvocation from there in realm.
> >>>> >
> >>>> > Am I in the right direction? Any suggestions?
> >>>> >
> >>>> >
> >>>> >
> >>>> > [1]
> >>>> >
> >>>>
> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
> >>>> > [2] http://tynamo.org/tapestry-security-jpa+guide
> >>>> > [3]
> >>>> >
> >>>>
> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
> >>>> > [4]
> >>>> >
> >>>>
> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
> >>>> >
> >>>> > --
> >>>> > Dmitry Gusev
> >>>> >
> >>>> > AnjLab Team
> >>>> > http://anjlab.com
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Dmitry Gusev
> >>>
> >>> AnjLab Team
> >>> http://anjlab.com
> >>>
> >>
> >>
> >>
> >> --
> >> Dmitry Gusev
> >>
> >> AnjLab Team
> >> http://anjlab.com
> >>
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Kalle Korhonen <ka...@gmail.com>.
Applied, excellent patch thanks!
Kalle
On Thu, Oct 11, 2012 at 3:35 PM, Dmitry Gusev <dm...@gmail.com> wrote:
> Done:
>
> http://jira.codehaus.org/browse/TYNAMO-183
>
>
> On Fri, Oct 12, 2012 at 1:46 AM, Dmitry Gusev <dm...@gmail.com>wrote:
>
>> Using @Core annotation helped:
>>
>> @Match("*")
>>
>> @Order("before:*")
>>
>> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
>>
>> final @Core Environment environment)
>>
>>
>> On Fri, Oct 12, 2012 at 12:59 AM, Dmitry Gusev <dm...@gmail.com>wrote:
>>
>>> Ok, I'm working on the patch now.
>>>
>>> I have a problem injecting Environment instance into advisor method in
>>> SecurityModule:
>>>
>>> @Match("*")
>>>
>>> @Order("before:*")
>>>
>>> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
>>>
>>> final Environment environment)
>>>
>>> this issue was already filed in JIRA:
>>>
>>> https://issues.apache.org/jira/browse/TAP5-1045
>>>
>>>
>>> Caused by: java.lang.IllegalStateException: Construction of service
>>> 'AssetObjectProvider' has failed due to recursion: the service depends on
>>> itself in some way. Please check
>>> org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource,
>>> TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via
>>> org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at
>>> TapestryModule.java:308) for references to another service that is itself
>>> dependent on service 'AssetObjectProvider'.
>>>
>>> at
>>> org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(
>>> RecursiveServiceCreationCheckWrapper.java:52)
>>>
>>>
>>>
>>> On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen <
>>> kalle.o.korhonen@gmail.com> wrote:
>>>
>>>> Instance-level access control is a very interesting topic to me. I say
>>>> you are pretty much on the right track if you want to use the
>>>> permission model. You wouldn't *necessarily* need to change anything
>>>> in Shiro if you just did programmatic checks with isPermitted and you
>>>> knew the right permissions at the time you are creating the
>>>> AuthorizationInfo. However, that model is cumbersome as you need to
>>>> create all the permissions upfront and then later formulate specific
>>>> ones when doing an authorization check - and you still couldn't use
>>>> annotations. Alex' syntax is one way to go about and you certainly
>>>> need some property substitution syntax for doing instance level checks
>>>> with annotations. Using the environment for fetching the
>>>> MethodInvocation sounds reasonable and I'm open to adding that as a
>>>> patch to tapestry-security. That way everybody at least wouldn't need
>>>> to introduce their own annotations.
>>>>
>>>> Entity-Relationship Based Access control is a completely different
>>>> take on the same topic. It's based on the idea that the data objects
>>>> you are trying to secure are in one way or another associated to the
>>>> currently executing subject. It greatly simplifies the syntax required
>>>> but obviously limits the possibilities as well. You wouldn't
>>>> necessarily need a "DAO" but still, some single, uniformed way of
>>>> accessing the data objects. The current implementation works at the
>>>> (JPA) EntityManager level.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dm...@gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I need to implement instance-level access control in my application
>>>> using
>>>> > tapestry-security.
>>>> >
>>>> > I already asked similar question here [1].
>>>> >
>>>> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
>>>> > tapestry-security.
>>>> >
>>>> > I looked at Entity-Relationship Based Access Control [2].
>>>> >
>>>> > This is not exactly what I need, because I don't even have DAO layer
>>>> > involved here.
>>>> >
>>>> > Here's what I have. I have business method in one of my services:
>>>> >
>>>> > @RequiresPermissions("task:submit")
>>>> >
>>>> > void submitTask(Task newTask);
>>>> >
>>>> > I read about ILAC on Shiro's web site [2].
>>>> >
>>>> > This looks similar, but in my domain not every user may submit every
>>>> task
>>>> > for execution.
>>>> > I have custom logic that should inspect instance of the newTask and
>>>> decide
>>>> > whether current user has permissions to submit the task for execution
>>>> or
>>>> > not.
>>>> >
>>>> > In Shiro's documentation [3] there's a note that tells that a
>>>> developer may
>>>> > write its own implementation of AuthorizingRealm.isPermitted(*) to
>>>> check
>>>> > permissions against custom domain model. I'm not sure about this in my
>>>> > case, though, because this note is given in 'Performance
>>>> Considerations'
>>>> > section.
>>>> >
>>>> > One more thing that stops me from overriding
>>>> AuthorizingRealm.isPermitted(*) is
>>>> > I don't have access to invocation context, i.e. I can't get instance
>>>> of the
>>>> > newTask from example above:
>>>> >
>>>> > AuthorizingRealm realm = new AuthorizingRealm()
>>>> >
>>>> > {
>>>> >
>>>> > @Override
>>>> >
>>>> > public boolean isPermitted(PrincipalCollection principals,
>>>> > Permission permission) {
>>>> >
>>>> > // XXX ... can't access to newTask instance
>>>> >
>>>> > }
>>>> >
>>>> >
>>>> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by
>>>> putting
>>>> > MethodInvocation into Tapestry Environment service instance and getting
>>>> > this MethodInvocation from there in realm.
>>>> >
>>>> > Am I in the right direction? Any suggestions?
>>>> >
>>>> >
>>>> >
>>>> > [1]
>>>> >
>>>> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
>>>> > [2] http://tynamo.org/tapestry-security-jpa+guide
>>>> > [3]
>>>> >
>>>> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
>>>> > [4]
>>>> >
>>>> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
>>>> >
>>>> > --
>>>> > Dmitry Gusev
>>>> >
>>>> > AnjLab Team
>>>> > http://anjlab.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Dmitry Gusev
>>>
>>> AnjLab Team
>>> http://anjlab.com
>>>
>>
>>
>>
>> --
>> Dmitry Gusev
>>
>> AnjLab Team
>> http://anjlab.com
>>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Dmitry Gusev <dm...@gmail.com>.
Done:
http://jira.codehaus.org/browse/TYNAMO-183
On Fri, Oct 12, 2012 at 1:46 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> Using @Core annotation helped:
>
> @Match("*")
>
> @Order("before:*")
>
> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
>
> final @Core Environment environment)
>
>
> On Fri, Oct 12, 2012 at 12:59 AM, Dmitry Gusev <dm...@gmail.com>wrote:
>
>> Ok, I'm working on the patch now.
>>
>> I have a problem injecting Environment instance into advisor method in
>> SecurityModule:
>>
>> @Match("*")
>>
>> @Order("before:*")
>>
>> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
>>
>> final Environment environment)
>>
>> this issue was already filed in JIRA:
>>
>> https://issues.apache.org/jira/browse/TAP5-1045
>>
>>
>> Caused by: java.lang.IllegalStateException: Construction of service
>> 'AssetObjectProvider' has failed due to recursion: the service depends on
>> itself in some way. Please check
>> org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource,
>> TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via
>> org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at
>> TapestryModule.java:308) for references to another service that is itself
>> dependent on service 'AssetObjectProvider'.
>>
>> at
>> org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(
>> RecursiveServiceCreationCheckWrapper.java:52)
>>
>>
>>
>> On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen <
>> kalle.o.korhonen@gmail.com> wrote:
>>
>>> Instance-level access control is a very interesting topic to me. I say
>>> you are pretty much on the right track if you want to use the
>>> permission model. You wouldn't *necessarily* need to change anything
>>> in Shiro if you just did programmatic checks with isPermitted and you
>>> knew the right permissions at the time you are creating the
>>> AuthorizationInfo. However, that model is cumbersome as you need to
>>> create all the permissions upfront and then later formulate specific
>>> ones when doing an authorization check - and you still couldn't use
>>> annotations. Alex' syntax is one way to go about and you certainly
>>> need some property substitution syntax for doing instance level checks
>>> with annotations. Using the environment for fetching the
>>> MethodInvocation sounds reasonable and I'm open to adding that as a
>>> patch to tapestry-security. That way everybody at least wouldn't need
>>> to introduce their own annotations.
>>>
>>> Entity-Relationship Based Access control is a completely different
>>> take on the same topic. It's based on the idea that the data objects
>>> you are trying to secure are in one way or another associated to the
>>> currently executing subject. It greatly simplifies the syntax required
>>> but obviously limits the possibilities as well. You wouldn't
>>> necessarily need a "DAO" but still, some single, uniformed way of
>>> accessing the data objects. The current implementation works at the
>>> (JPA) EntityManager level.
>>>
>>> Kalle
>>>
>>>
>>> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dm...@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I need to implement instance-level access control in my application
>>> using
>>> > tapestry-security.
>>> >
>>> > I already asked similar question here [1].
>>> >
>>> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
>>> > tapestry-security.
>>> >
>>> > I looked at Entity-Relationship Based Access Control [2].
>>> >
>>> > This is not exactly what I need, because I don't even have DAO layer
>>> > involved here.
>>> >
>>> > Here's what I have. I have business method in one of my services:
>>> >
>>> > @RequiresPermissions("task:submit")
>>> >
>>> > void submitTask(Task newTask);
>>> >
>>> > I read about ILAC on Shiro's web site [2].
>>> >
>>> > This looks similar, but in my domain not every user may submit every
>>> task
>>> > for execution.
>>> > I have custom logic that should inspect instance of the newTask and
>>> decide
>>> > whether current user has permissions to submit the task for execution
>>> or
>>> > not.
>>> >
>>> > In Shiro's documentation [3] there's a note that tells that a
>>> developer may
>>> > write its own implementation of AuthorizingRealm.isPermitted(*) to
>>> check
>>> > permissions against custom domain model. I'm not sure about this in my
>>> > case, though, because this note is given in 'Performance
>>> Considerations'
>>> > section.
>>> >
>>> > One more thing that stops me from overriding
>>> AuthorizingRealm.isPermitted(*) is
>>> > I don't have access to invocation context, i.e. I can't get instance
>>> of the
>>> > newTask from example above:
>>> >
>>> > AuthorizingRealm realm = new AuthorizingRealm()
>>> >
>>> > {
>>> >
>>> > @Override
>>> >
>>> > public boolean isPermitted(PrincipalCollection principals,
>>> > Permission permission) {
>>> >
>>> > // XXX ... can't access to newTask instance
>>> >
>>> > }
>>> >
>>> >
>>> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by
>>> putting
>>> > MethodInvocation into Tapestry Environment service instance and getting
>>> > this MethodInvocation from there in realm.
>>> >
>>> > Am I in the right direction? Any suggestions?
>>> >
>>> >
>>> >
>>> > [1]
>>> >
>>> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
>>> > [2] http://tynamo.org/tapestry-security-jpa+guide
>>> > [3]
>>> >
>>> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
>>> > [4]
>>> >
>>> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
>>> >
>>> > --
>>> > Dmitry Gusev
>>> >
>>> > AnjLab Team
>>> > http://anjlab.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Dmitry Gusev
>>
>> AnjLab Team
>> http://anjlab.com
>>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Dmitry Gusev <dm...@gmail.com>.
Using @Core annotation helped:
@Match("*")
@Order("before:*")
public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
final @Core Environment environment)
On Fri, Oct 12, 2012 at 12:59 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> Ok, I'm working on the patch now.
>
> I have a problem injecting Environment instance into advisor method in
> SecurityModule:
>
> @Match("*")
>
> @Order("before:*")
>
> public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
>
> final Environment environment)
>
> this issue was already filed in JIRA:
>
> https://issues.apache.org/jira/browse/TAP5-1045
>
>
> Caused by: java.lang.IllegalStateException: Construction of service
> 'AssetObjectProvider' has failed due to recursion: the service depends on
> itself in some way. Please check
> org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource,
> TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via
> org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at
> TapestryModule.java:308) for references to another service that is itself
> dependent on service 'AssetObjectProvider'.
>
> at
> org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(
> RecursiveServiceCreationCheckWrapper.java:52)
>
>
>
> On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen <
> kalle.o.korhonen@gmail.com> wrote:
>
>> Instance-level access control is a very interesting topic to me. I say
>> you are pretty much on the right track if you want to use the
>> permission model. You wouldn't *necessarily* need to change anything
>> in Shiro if you just did programmatic checks with isPermitted and you
>> knew the right permissions at the time you are creating the
>> AuthorizationInfo. However, that model is cumbersome as you need to
>> create all the permissions upfront and then later formulate specific
>> ones when doing an authorization check - and you still couldn't use
>> annotations. Alex' syntax is one way to go about and you certainly
>> need some property substitution syntax for doing instance level checks
>> with annotations. Using the environment for fetching the
>> MethodInvocation sounds reasonable and I'm open to adding that as a
>> patch to tapestry-security. That way everybody at least wouldn't need
>> to introduce their own annotations.
>>
>> Entity-Relationship Based Access control is a completely different
>> take on the same topic. It's based on the idea that the data objects
>> you are trying to secure are in one way or another associated to the
>> currently executing subject. It greatly simplifies the syntax required
>> but obviously limits the possibilities as well. You wouldn't
>> necessarily need a "DAO" but still, some single, uniformed way of
>> accessing the data objects. The current implementation works at the
>> (JPA) EntityManager level.
>>
>> Kalle
>>
>>
>> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dm...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I need to implement instance-level access control in my application
>> using
>> > tapestry-security.
>> >
>> > I already asked similar question here [1].
>> >
>> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
>> > tapestry-security.
>> >
>> > I looked at Entity-Relationship Based Access Control [2].
>> >
>> > This is not exactly what I need, because I don't even have DAO layer
>> > involved here.
>> >
>> > Here's what I have. I have business method in one of my services:
>> >
>> > @RequiresPermissions("task:submit")
>> >
>> > void submitTask(Task newTask);
>> >
>> > I read about ILAC on Shiro's web site [2].
>> >
>> > This looks similar, but in my domain not every user may submit every
>> task
>> > for execution.
>> > I have custom logic that should inspect instance of the newTask and
>> decide
>> > whether current user has permissions to submit the task for execution or
>> > not.
>> >
>> > In Shiro's documentation [3] there's a note that tells that a developer
>> may
>> > write its own implementation of AuthorizingRealm.isPermitted(*) to check
>> > permissions against custom domain model. I'm not sure about this in my
>> > case, though, because this note is given in 'Performance Considerations'
>> > section.
>> >
>> > One more thing that stops me from overriding
>> AuthorizingRealm.isPermitted(*) is
>> > I don't have access to invocation context, i.e. I can't get instance of
>> the
>> > newTask from example above:
>> >
>> > AuthorizingRealm realm = new AuthorizingRealm()
>> >
>> > {
>> >
>> > @Override
>> >
>> > public boolean isPermitted(PrincipalCollection principals,
>> > Permission permission) {
>> >
>> > // XXX ... can't access to newTask instance
>> >
>> > }
>> >
>> >
>> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by
>> putting
>> > MethodInvocation into Tapestry Environment service instance and getting
>> > this MethodInvocation from there in realm.
>> >
>> > Am I in the right direction? Any suggestions?
>> >
>> >
>> >
>> > [1]
>> >
>> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
>> > [2] http://tynamo.org/tapestry-security-jpa+guide
>> > [3]
>> >
>> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
>> > [4]
>> >
>> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
>> >
>> > --
>> > Dmitry Gusev
>> >
>> > AnjLab Team
>> > http://anjlab.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Dmitry Gusev <dm...@gmail.com>.
Ok, I'm working on the patch now.
I have a problem injecting Environment instance into advisor method in
SecurityModule:
@Match("*")
@Order("before:*")
public static void adviseSecurityAssert(MethodAdviceReceiver receiver,
final Environment environment)
this issue was already filed in JIRA:
https://issues.apache.org/jira/browse/TAP5-1045
Caused by: java.lang.IllegalStateException: Construction of service
'AssetObjectProvider' has failed due to recursion: the service depends on
itself in some way. Please check
org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource,
TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via
org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at
TapestryModule.java:308) for references to another service that is itself
dependent on service 'AssetObjectProvider'.
at
org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(
RecursiveServiceCreationCheckWrapper.java:52)
On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> Instance-level access control is a very interesting topic to me. I say
> you are pretty much on the right track if you want to use the
> permission model. You wouldn't *necessarily* need to change anything
> in Shiro if you just did programmatic checks with isPermitted and you
> knew the right permissions at the time you are creating the
> AuthorizationInfo. However, that model is cumbersome as you need to
> create all the permissions upfront and then later formulate specific
> ones when doing an authorization check - and you still couldn't use
> annotations. Alex' syntax is one way to go about and you certainly
> need some property substitution syntax for doing instance level checks
> with annotations. Using the environment for fetching the
> MethodInvocation sounds reasonable and I'm open to adding that as a
> patch to tapestry-security. That way everybody at least wouldn't need
> to introduce their own annotations.
>
> Entity-Relationship Based Access control is a completely different
> take on the same topic. It's based on the idea that the data objects
> you are trying to secure are in one way or another associated to the
> currently executing subject. It greatly simplifies the syntax required
> but obviously limits the possibilities as well. You wouldn't
> necessarily need a "DAO" but still, some single, uniformed way of
> accessing the data objects. The current implementation works at the
> (JPA) EntityManager level.
>
> Kalle
>
>
> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dm...@gmail.com>
> wrote:
> > Hi,
> >
> > I need to implement instance-level access control in my application using
> > tapestry-security.
> >
> > I already asked similar question here [1].
> >
> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
> > tapestry-security.
> >
> > I looked at Entity-Relationship Based Access Control [2].
> >
> > This is not exactly what I need, because I don't even have DAO layer
> > involved here.
> >
> > Here's what I have. I have business method in one of my services:
> >
> > @RequiresPermissions("task:submit")
> >
> > void submitTask(Task newTask);
> >
> > I read about ILAC on Shiro's web site [2].
> >
> > This looks similar, but in my domain not every user may submit every task
> > for execution.
> > I have custom logic that should inspect instance of the newTask and
> decide
> > whether current user has permissions to submit the task for execution or
> > not.
> >
> > In Shiro's documentation [3] there's a note that tells that a developer
> may
> > write its own implementation of AuthorizingRealm.isPermitted(*) to check
> > permissions against custom domain model. I'm not sure about this in my
> > case, though, because this note is given in 'Performance Considerations'
> > section.
> >
> > One more thing that stops me from overriding
> AuthorizingRealm.isPermitted(*) is
> > I don't have access to invocation context, i.e. I can't get instance of
> the
> > newTask from example above:
> >
> > AuthorizingRealm realm = new AuthorizingRealm()
> >
> > {
> >
> > @Override
> >
> > public boolean isPermitted(PrincipalCollection principals,
> > Permission permission) {
> >
> > // XXX ... can't access to newTask instance
> >
> > }
> >
> >
> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by
> putting
> > MethodInvocation into Tapestry Environment service instance and getting
> > this MethodInvocation from there in realm.
> >
> > Am I in the right direction? Any suggestions?
> >
> >
> >
> > [1]
> >
> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
> > [2] http://tynamo.org/tapestry-security-jpa+guide
> > [3]
> >
> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
> > [4]
> >
> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Kalle Korhonen <ka...@gmail.com>.
Instance-level access control is a very interesting topic to me. I say
you are pretty much on the right track if you want to use the
permission model. You wouldn't *necessarily* need to change anything
in Shiro if you just did programmatic checks with isPermitted and you
knew the right permissions at the time you are creating the
AuthorizationInfo. However, that model is cumbersome as you need to
create all the permissions upfront and then later formulate specific
ones when doing an authorization check - and you still couldn't use
annotations. Alex' syntax is one way to go about and you certainly
need some property substitution syntax for doing instance level checks
with annotations. Using the environment for fetching the
MethodInvocation sounds reasonable and I'm open to adding that as a
patch to tapestry-security. That way everybody at least wouldn't need
to introduce their own annotations.
Entity-Relationship Based Access control is a completely different
take on the same topic. It's based on the idea that the data objects
you are trying to secure are in one way or another associated to the
currently executing subject. It greatly simplifies the syntax required
but obviously limits the possibilities as well. You wouldn't
necessarily need a "DAO" but still, some single, uniformed way of
accessing the data objects. The current implementation works at the
(JPA) EntityManager level.
Kalle
On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <dm...@gmail.com> wrote:
> Hi,
>
> I need to implement instance-level access control in my application using
> tapestry-security.
>
> I already asked similar question here [1].
>
> There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
> tapestry-security.
>
> I looked at Entity-Relationship Based Access Control [2].
>
> This is not exactly what I need, because I don't even have DAO layer
> involved here.
>
> Here's what I have. I have business method in one of my services:
>
> @RequiresPermissions("task:submit")
>
> void submitTask(Task newTask);
>
> I read about ILAC on Shiro's web site [2].
>
> This looks similar, but in my domain not every user may submit every task
> for execution.
> I have custom logic that should inspect instance of the newTask and decide
> whether current user has permissions to submit the task for execution or
> not.
>
> In Shiro's documentation [3] there's a note that tells that a developer may
> write its own implementation of AuthorizingRealm.isPermitted(*) to check
> permissions against custom domain model. I'm not sure about this in my
> case, though, because this note is given in 'Performance Considerations'
> section.
>
> One more thing that stops me from overriding AuthorizingRealm.isPermitted(*) is
> I don't have access to invocation context, i.e. I can't get instance of the
> newTask from example above:
>
> AuthorizingRealm realm = new AuthorizingRealm()
>
> {
>
> @Override
>
> public boolean isPermitted(PrincipalCollection principals,
> Permission permission) {
>
> // XXX ... can't access to newTask instance
>
> }
>
>
> I was thinking about fixing Tynamo's SecurityInterceptor advise, by putting
> MethodInvocation into Tapestry Environment service instance and getting
> this MethodInvocation from there in realm.
>
> Am I in the right direction? Any suggestions?
>
>
>
> [1]
> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
> [2] http://tynamo.org/tapestry-security-jpa+guide
> [3]
> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
> [4]
> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tynamo tapestry-security Instance-Level Access Control?
Posted by Alex Kotchnev <ak...@gmail.com>.
I also struggled with something similar and came up with a somewhat
different solution from instance level access control, specifically for
pages (which doesn't seem to fit your need, but I'll mention it anyway). On
a previous project in Grails, we used the Grails Shiro plugin (
http://grails.org/plugin/shiro) , which sets up "by convention"
permissions, where each action that runs requires a permission of the type
"domain:action:id" - e.g. if I want to access book:show:1 , I need to have
the relevant permission (e.g. book:show:1, or book:show:*, or book:*, etc).
In order to implement a similar approach in Tapestry, I added a new
annotation
@DynRequiresPermissions(value = "book:@bookId", tokens = "@bookId=%1s")
// this basically means that shiro will look for a permission
book:@bookIdwhere @bookId is substituted with the first activation
context parameter
class Show {
}
At login time, the user receives the static permissions that they actually
have (e.g. book:1) based on their roles and company membership, and I have
a component request filter that transforms the @DynRequiresPermissions
annotation values into the actual permission that is needed (e.g. from
book:@bookId => book:1), and then passes the permission check to Shiro.
This works reasonably well, as the set of permissions that a user has is
fairly static - once a user is created for the given company and are given
access to a certain set of resources, that doesn't change very often. I
currently don't use the isPermitted, but now that you mentioned it, I
should probably consider doing it (instead of refreshing the static/cached
permissions whenever the user state/access changes).
I'm not sure if this helps but might give you some ideas.
Cheers,
Alex K
On Thu, Oct 11, 2012 at 9:38 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> Hi,
>
> I need to implement instance-level access control in my application using
> tapestry-security.
>
> I already asked similar question here [1].
>
> There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's
> tapestry-security.
>
> I looked at Entity-Relationship Based Access Control [2].
>
> This is not exactly what I need, because I don't even have DAO layer
> involved here.
>
> Here's what I have. I have business method in one of my services:
>
> @RequiresPermissions("task:submit")
>
> void submitTask(Task newTask);
>
> I read about ILAC on Shiro's web site [2].
>
> This looks similar, but in my domain not every user may submit every task
> for execution.
> I have custom logic that should inspect instance of the newTask and decide
> whether current user has permissions to submit the task for execution or
> not.
>
> In Shiro's documentation [3] there's a note that tells that a developer may
> write its own implementation of AuthorizingRealm.isPermitted(*) to check
> permissions against custom domain model. I'm not sure about this in my
> case, though, because this note is given in 'Performance Considerations'
> section.
>
> One more thing that stops me from overriding
> AuthorizingRealm.isPermitted(*) is
> I don't have access to invocation context, i.e. I can't get instance of the
> newTask from example above:
>
> AuthorizingRealm realm = new AuthorizingRealm()
>
> {
>
> @Override
>
> public boolean isPermitted(PrincipalCollection principals,
> Permission permission) {
>
> // XXX ... can't access to newTask instance
>
> }
>
>
> I was thinking about fixing Tynamo's SecurityInterceptor advise, by putting
> MethodInvocation into Tapestry Environment service instance and getting
> this MethodInvocation from there in realm.
>
> Am I in the right direction? Any suggestions?
>
>
>
> [1]
>
> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html
> [2] http://tynamo.org/tapestry-security-jpa+guide
> [3]
>
> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl
> [4]
>
> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>