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]
