Hi Dan, Your last option seems the most feasible option to me.
I presume I write my own permission-implementation then (for every domain class if necessary) to be used by "public List<String> visibleTo();"? Would really like you to guide me. Where to start? ________________________________________ From: Dan Haywood [[email protected]] Sent: Friday, April 04, 2014 10:26 AM To: users Subject: Re: per instance security On 4 April 2014 09:03, Erik de Hair <[email protected]> wrote: > Hi, > > I need per instance security in my application. What I want to do is > extend AuthorisationRealm with doGetAuthorisationInfo() and implement my > own permissions-scheme to check for the users permissions for a certain > domain model instance. > > I'm not sure that's the way to solve this. With Shiro, the permission strings correspond to class members (possibly wildcarded to all members in a class, or to all classes in a package etc). So it is a class-based security mechanism, not an instance-based one. That said, the way in which Shiro parses the permission string is pluggable, so in theory one could have a different permission scheme that includes the OIDs of objects (Company/L_10). But I don't think it'd be a very maintainable approach (lots of fiddly data to setup). So I feel a better way to address this is up a level, within Isis.... Do I have to check for these permissions myself You could, if you wanted, put the code in the domain objects, eg in the hide or disable methods, and get hold of the current user from getContainer(). But that would litter your domain code with lots of security stuff, which sounds unappealing. Or... what I would probably explore is if there is some sort of convention whereby you could write a custom facet (implementing HidingInteractionAdvisor or DisablingInteractionAdvisor) such that you could do the per-instance security as a cross-cutting concern. For example, each object that requires per-instance security could implement an interface: public interface SecuredPerInstance { // return the user or roles that this instance is visible for @Programmatic public List<String> visibleTo(); // return the user or roles that this instance can be used by (modifiable, invoke actions) @Programmatic public List<String> usableBy(); } Then classes that need security would implement this instance, and the facet would advise based on the facet. If that makes sense, I can guide you in writing such a facet if need be. HTH Dan and throw a security exception in case of no permission or is this > automatically done by Shiro when a client calls the restful interface like: > > http://localhost:8080/restful/objects/nl.pocos.dom.Company/L_10 > > Regards, > Erik >
