User roles vs. user permissions using apache shiro

Question

I am trying to model some complex permission management system using apache shiro.

English not being my native tongue I am afraid I might be missing some of the subtleties of terms such as "Roles", "Permissions", "Rights" & "privileges".

For example lets say I want to create a system that manages resources such as printers located inside buildings. A DB holds the information of which printer is located in what building. Users of that system should be able to reset a printer or print to it.

Its clear to me that some users will be "Super Admins" and be able to reset and print to any printer ('printer:*:*')- I guess that we could say that those people have a "Super Admin Role".

But what if someone should be allowed to reset the printers in a specific building ('building:A:*') ? Is "Building Admin" a (prarametric) role? or is this just a permission on a specific building? How would you model this using apache Shiro?

n.b.
When tagging this Q I added the user-roles tag and it says:"A user role is a group of users that share the same privileges or permissions on a system. Use this tag for questions about how user roles work in a particular security framework, or questions about the implementation of user roles in your program."

Would I be correct to assume that based on this definition there is not such role as a "Building Admin" because being an Admin of Building A does not give you the same permissions as does being an Admin of building B? and if so, what would be the correct terminology to describe a "Building admin"?

Answer 1

Have you considered using more than three tokens within the WildCardPermission format?

There is no limit to the number of tokens that can be used, so it is up to your imagination in terms of ways that this could be used in your application.

— WildCardPermission Javadoc

Instead of the domain:action:instance syntax commonly used in Apache Shiro examples and documentation, you could add another token to represent the building, e.g. printer:print,reset:*:buildingA.

The downside of this scheme is that whenever you are checking if an action is permitted on a particular printer, you'd now also have to specify the location, even though the token representing the printer instance might already uniquely identify that printer:

// let's say the role for buildingA-admin has permission of "printer:*:*:buildingA"

subject.isPermitted("printer:print:epson123:buildingA"); // returns true
subject.isPermitted("printer:print:epson123"); // returns false

Depending on your application domain, maybe a structure like buildingA:printer:print,reset:epson123 might even be more appropriate or useful.

---

To answer your other question regarding user roles, you'd be correct to assume that if you have both buildingA-admin and buildingB-admin roles, they are different user roles, if the permissions assigned to them are not the same.
You might conceive a general user role of Building Admin for permissions that all admins for the different buildings might have in common, to avoid duplicating those permissions across the different building-specific admin roles.