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
