It's my 1st time i'm working with Yii2's RBAC system.
I used http://www.yiiframework.com/doc-2.0/guide-security-authorization.html to get myself familiar with topic.
As i needed some kind of administration for roles / permissions, i installed this extension: https://github.com/mdmsoft/yii2-admin
I'm working on application that let's users submit articles. There are two kind of users, Administrators, and normal Users.
I created 2 roles for that purpose. Admin role and User role.
Users (both admins and users) must have ability to edit articles. Admins should be able to edit any article, while users can edit only their own articles.
For that i created 2 permissions. "Edit" permission and "EditOwn" permission. Than i created "IsOwner" rule and attached it to "EditOwn" permission.
I assigned "Edit" permission to Admin role, and "EditOwn" to User role and everything works great.
Now i'd like to create "lock" status for each article. If Article is locked, user can not edit it even if it's he's own article. Admins should be able to edit it even if it's locked.
For that i created new rule "IsLocked" but i dont know how to add it to "EditOwn" permission. I don't know is it even possible to have 2 rules attached to one permission?
EDIT:
Right now, i have this "dealt with" in way that i have additional permission "EditOwnIsLocked" to which i attached "IsLocked" rule which is than child of "EditOwn", which is child of "Edit".
This works, but it feels dirty and plain and simple wrong.
As it turns out, there is (for now) no way to attach multiple rules to a permission.
You can deal with need of multiple rules in way i do right now, by creating additional permission and attach rule to it and than make child<->parent connection, or you can edit your rule to check for all situations (in my case to check for IsParent and IsLocked).
Those solutions arn't perfect but it's what it is for now. First solution spawns unnecessary permissions, and clutter your permission list (in case you are using yii2-admin or similar extensions), but keeps your rules clean, and second solution keeps your permission list clean but makes you retype same code in multiple rules which is kinda oposit of what OOP stands for.
Related
I have developed a pretty standard and common authorization permission system for an internal business web application.
There are some roles with permission sets; system administrator can create new roles and assign permissions to them; every web controller method has an attribute to check for specific permission. So far so good.
But then I have the following conversation with the customer:
Customer: "Please, make it possible to hide specific form fields in specific forms for a specific role".
I: "Ok, so the users of this role shouldn't have permissions to modify these fields, right? I can also add a permission check to the method that saves the data."
Customer: "No, no, it's not a permission issue as such, it's just about convenience - this role doesn't need to work with these fields and we want to make the UI less cluttered. The users of this role shouldn't see these fields in this form only; however, there are other forms where it's totally OK to see these fields. Of course, we might later create new roles that will need to see these fields in this form, but by default the fields should be hidden."
And so the permission system gets cluttered with "pseudo-permissions", such as "See field X in form Y". They exist for UI convenience purposes only and have nothing to do with authorization for performing activities on data.
Is it a good practice to control UI through roles & permissions, even when the specific permission has nothing to do with data processing authorization? Is there a clean solution to avoid cluttering the permission system implementation with such UI-only pseudo-permissions and still provide the customer with granular control to achieve cleaner UI for specific roles?
I'm working on a project in Yii, and I have almost no experience with this framework and php.
I'm trying to give access to a view in Yii to different users depending on their role. In my code, in the Controller/accessRules function, I give permission to users with a specific role, that's working fine.
The thing/problem is: I also need to give that same permission to a specific users from very different roles and those roles they don't have to have permission. But those specific users they have a field activated in the 'users' table in the database (it's a boolean field, 1/0 values). If that field has a '1', those users must access to the view, if it's a '0', they don't.
I tried to check the value of the field I described before but the thing is if they don't have the role described in the accessRules, they don't have access. (or maybe the way I check this is not well done).
What I need to do to solve this? I need some tips.
Thanks!
Well, I finally found a solution. Not the one I was expecting but effective... I created a new role/profile in the database and added the role to the users I want to give access, also in the database. Then in the app I added the new role in the controller/action of the view, that's all. It's simple, I know. But I think it's not the best idea because of if the number of users starts growing and in the case every user needs a specific role...maybe it's too much work.
I am working with a lot of MODX since 2010. From time to time i coudl need another user group with restricted permissions. Like "Can edit content, but not change settings". So the user can't break anything which is relevant for die CMS itself.
I added users, placed them into roles and groups, but somehow it never works the way I expect it to work. A role is not a "role" but a level of authority. A group is just a link to a set of permissions, which is already setup as a ruleset. Still, if I create and setup the group "content editor", I never get it running as expected.
Is there a guide (or even an extra?) to setup restricted user account without breaking ones brain?
There's a basic tutorial available in the official documentation: https://docs.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/giving-a-user-manager-access
My personal recommendation would be to ignore roles altogether. Whenever you need to enter a role (when adding a policy to a user group, or when adding a user group to a user) just pick "Super User - 0". They're an added complexity to allow, essentially, different permissions within the same user group, that 99% of the people don't need.
The primary thing to do is to create a policy, based on the "Administrator" policy set, that contains the permissions you want the user to have in the manager. Those would include the relevant resource/document permissions, but not settings, for example.
Then you add that policy to the user group of your choice as a "mgr" context policy.
The usergroup will also need context permission to be able of interacting with specific contexts. So on the contexts tab in permissions, add the different contexts you want, with the contexts policy.
As #optimuscrime commented, ACLs can be a little complicated, but that's the general approach.
Currently I'm building a web app. So far I only have regular users. However, due to some requirements I need to have special admin accounts for the app administrators. I'm wondering now how these are usually implemented. The requirement is, that they use the same login mask as regular users and behave the same except for the additional capabilities. To differentiate I could put an admin flag into the users' profile or put the admins into a separate table in my DB. Maybe the the second option scales better for potential additional user groups. Also, how could these admins be signed up? I don't want to use predefined usernames I check against in the login handler. I know the question is rather general. I'm just looking for some directions.
Since you didn't give information about the platform(s) you are using, I can only give theoretical answer. While a simple "isadmin checkbox" will do the job for only separating normal users and admins, but if you will need another user type such as "power users" etc. you will keep adding new columns to your table, which is not ideal. Basically you can use a "Role Based" or a "Permission" based approach. In Role based, as the name implies, you assign each user a role and give access to specific resources depending on the role. In the "Permissions" approach you define for each user the permissions they have (resources to access, actions they can perform). Also you could combine these two approaches, where you assign each user his role and define permissions for each role.
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"?
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.