shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject @RequiresAssociation
Date Mon, 06 Dec 2010 17:29:16 GMT
In my projects, I repeatedly find a need to express a permission rule
for allowing the currently executing subject to access or modify an
instance of a persistent type when the subject is in some way
associated to the said instance. For example, a user should only be
allowed update his own profile. I had implemented this
association/instance based security concept for Trails framework (see
http://trails.codehaus.org/Security+module) earlier and now, I'd like
to be able to do the same for tapestry-security
(http://tynamo.org/tapestry-security+guide). With the more flexible
@RequiresPermissions you could theoretically implement much more
complex association-based permission rules but in practice I've found
that the security rules based on primary type's association to the
executing subject solves at least 80% of the use cases, which could be
expressed with a more specialized and simpler-to-use
@RequiresAssociation annotation.

I could simply implement @RequiresAssociation for tapestry-security
only, but I would assume that it would be equally useful for Wicket
and Grails and especially for any framework using Hibernate/JPA
persistence because add-on security rules are easy to express with the
criteria API. @RequiresAssociation could live in Shiro and have bare
bones support for it similar to @RequiresPermissions. Shiro-based
security libraries could then make more complete integrations with
their favorite web framework, utilizing the same annotation. Would
other Shiro devs and community find this useful and reasonable and
worth implementing in the Shiro core itself?

Kalle

Mime
View raw message