Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: pass (nike.apache.org: domain of kalle.o.korhonen@gmail.com
 designates 209.85.213.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=JjCV5JClYt75EtsVCIbDNGal3JT/PGl/+xdz9nl4NqM7RFRdWvmxJNbLqTIr+HLh5i
         Szn+cOQjxNXvvvLy7wGffQWvsYqDqThGM+yXspHBExryk41FQXUX5tv0p7Tuw00RQrmR
         UqKWsw+EqhROCC3igHIwyzirMXMrG6ItJH/tE=
MIME-Version: 1.0
Date: Mon, 6 Dec 2010 09:29:16 -0800
Message-ID: <AANLkTikLTVFtAsayRpDFiLuE8vDi_JULCiaMtM-BNoTO@mail.gmail.com>
Subject: @RequiresAssociation
From: Kalle Korhonen <kalle.o.korhonen@gmail.com>
To: dev@shiro.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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