I faced a similar situation where I needed perform some authorization logic
at a per instance level. There were some complex business rules that needed
to be applied base on type of permission a subject had, the type of
operation required and also based on the state of the instance to check in a
given workflow.

AOP to the rescue, I ended up with a security interceptor on top of the DAOs
that needed this kind of advanced authorization. With the aspect I was able
to perform the required logic based on the nature of the call on the DAO:
retrieve, update, delete.

HTH... like someone says


On Thu, Oct 20, 2011 at 11:39 AM, richs <[email protected]> wrote:

> Say you have a database containing millions of records
>
> You have a permission which states that you can delete record 1234 -
> "record:delete:1234"
>
> What is the best practice to check the authorization for instance 1234?
>  The
> method /AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
> principals)/ accepts a collection of principals, so does not contain the
> identifier 1234.  I don't want to add every record my user can delete to an
> AuthorizationInfo object
> (record:delete:0001,record:delete:0002,record:delete:0004, etc) as this
> could be 1000s.
>
> I can't see any easy way to hook in the callback to check instance 1234.
>
> Any ideas?
>
> Thanks
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Authroization-instance-level-checks-tp6913395p6913395.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Reply via email to