Hi Richard, Thanks very much for your reply.
I like your solution, although since most of our security checks are quite standard (i.e. just a domain and action) I'm not sure if it is worth making the changes now. I think for the initial version I will use two security checks (if needed) but I will keep your solution in mind as the software evolves. Cheers, Stuart On Thu, Aug 1, 2013 at 10:49 PM, Richard Adams <[email protected]>wrote: > Hi Stuart, > > We also have spent some time adapting the basic Shiro permission syntax > to our needs. We have ended up using a mixture of these permissions and > ACLs to make permission queries efficient. > > For each user or role, we have quite a list of permissions (maybe up to > about 20) for the different sorts of domains and actions they are > authorized for, and check this against a supplied argument containing the > characteristics of the resource we are authorizing. So for example, we > might have a permission string like > Document:edit:property_owner=$self, Form:read:*, > Document:read:group="Smith_Laboratory&date=2000/08/07-2006-05-04" > > which is then tested against an argument object that contains the domain, > action and properties of the object we're authorising, > > and iterate over the permissions. We check against domain, then action, > to efficiently eliminate mismatches. > > As you can see, we have customised the third part of the permissions > string to include relevant attributes such as the values of properrties of > an object, or group membership, or a date range ( in our application, > people can have authorised for operations on documents that were created > within a date range) > Once we've parsed this string into a Permission implementation, we cache > it, so for a smallish list the permissions check is a very small time > compared with the rest of the operation we're processing. > I'm not entirely confident that this is the best approach, but it is > working for us in a fairly complicated document management web application > with dynamic permissions, and testing against multiple permissions isn't a > problem for us. > > Best wishes > > Richard > On 1 Aug 2013, at 22:16, Stuart Broad wrote: > > Hi all, > > I have been thinking about using the wild card permissions within our > application but I am struggling with how to represent the following: > > (1) A user who has permission to edit themselves. > (2) A user who has permissions to edit people in the same department. > > The only option I have come up with is to represent permissions as follows: > > *user:updateSelf > * > *user:updateOther:<departmentX>* > > One problem with this is that it would potentially require two permission > checks. I had originally wanted just one permission like 'user:update'. > > In addition there is a possibility that we might need to add permissions > down to attribute level for some resources. Again the only way I can think > of representing this is to split it out as follows: > > *user:updateOwnEmail* > *user:updateOtherEmail:<departmentX>* > *...* > * > * > What do you think? I was hoping for a more hierarchical approach which > meant I could just use a single permission check in the code. > > I did think about generating the permissions from other information in the > database (i.e. not necessarily storing all the permissions as permissions > but I would like to stick with 'clear' permissions if possible). > > Any tips/pointers would be greatly appreciated as we have only just > started to use shiro and I would like to minimise our initial mistakes! > > Cheers, > > Stuart > > > > Richard Adams > [email protected] > > > > >
