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.gu...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
