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.
Related
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.
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.
I only want the person who I have assigned the task to see the task in the project module. I don't want other users of the project to see this persons tasks.
However currently any user who has user access rights can see all the tasks even if they were not assigned it.
Is there a work around this ?
OpenERP/Odoo has two kinds of security restrictions that can be assigned to a user group:
Access Rights are CRUD yes/no flags (similar to Unix FS permissions), and allow per-model access control. They state whether members of this group may perform a Create, Read, Update, and Delete operation on any document of a certain document model (e.g. a project task). The default policy is DENY, so by default any operation will be refused if the user does not explicitly have the right to perform it via one of her groups' access rights.
Record Rules are filters applied on CRUD operations, and allow per-document access-control, once access right are already granted. Users will only be able to perform an operation on a given document if the document matches at least one of the record rules. The default policy is ALLOW, so if no rule exists for a given model, all documents of that model may be accessed by users who have the necessary access rights.
Both Access Rights and Record Rules may also be defined globally without assigning them to a specific group, in which case they apply to everyone. There is one pitfall for Record Rules: global rules may NOT be relaxed by other rules (on purpose!), so use with care.
In your case it looks like you should define one extra Record Rule on the Project User group that explicitly restricts access on Project Tasks to your own tasks (and presumably those that are not assigned yet). You need to create a new entry in the Security Rules menu with these parameters:
object/model: project.task
name: See own tasks only
domain: ['|',('user_id','=',False),('user_id','=',user.id)]
(means: your own tasks and unassigned ones)
apply for read: [x]
apply for write: [x]
apply for create: [x]
apply for delete: [x]
groups: Project / User
The domain of a record rule is a standard OpenERP/Odoo domain that is evaluated on the records on which you are trying to perform the operation, and can refer to a user variable that contains the current user's data (technically, a browse_record on the current user). The documentation has a description of domain.
If you want to allow special users (e.g. Project Managers) to view all tasks in the system, you can relax this rule for them by adding another rule to the Project Manager group which allows access to all tasks. There is a special "domain filter" that means "ALLOW ALL" and is useful to relax another stricter rule: [(1,'=',1)].
Note 1: Have a look at the existing Record Rules to see what they're doing first, and be sure to read the explanations on the Record Rule form when you are adding yours. One important thing to keep in mind is that group-specific rules are combined with an OR operator. So if you add the rule I described above, you may not see any restriction effect because other group-specific rules are still giving access. You may have to disable them, edit them, or change the user group they apply to, to get the exact effect you want.
Note 2: Remember that if you do something wrong with Access Rights and Record Rules, you can always fix the mess with the admin account, as these security restrictions do not apply to the admin (similarly to the root user on Unix).
Note: In OpenERP 7 you have to modify or disable the defualt rule called
Project/Task: employees: public, portal, employee or following or
assigned
To get your rule working.
Create a new security rule, select Object as "project.task" ,give domain filter as [("user_id","=",user.id)]. No need to add any groups, so that it will be global. Thats it!
My problem was a bit more complex. I wanted to have users who can only their assigned tasks and some who can see the rest, too.
In Odoo 11 I found that the standard project user inherits Employees \ Employee which in turn has the rule Project/Task: employees: follow required for follower-only projects which let users see the other tasks.
What I did:
create a new group -> duplicate of Project / Users
implemented the rule from odony's answer -> ['|',('user_id','=',False),('user_id','=',user.id)]
removed the record rule Project/Task: employees: follow required for follower-only projects from Employees / Employee and added it to Project / Users
Now I can decide who is a project user, who can see all tasks of a project, and who is a worker, who only gets to see tasks assigned to them.
As already pointed by #user1534055 in openERP 7, it's a bit-different.
Find the rule named Project/Task: employees: public, portal, employee or following or assigned
Edit it and remove ('project_id.privacy_visibility', 'in', ['public', 'portal', 'employees']),
'&', from the rule definition and hit Save.
After this tasks will be visible to only those who've been assigned.
I work on a vb.net winforms app where we currently are using simple roles for security. We enable/disable specific controls based on if the current user has the required role. We are to the point where this is no longer granular enough.
Our application is based on different physical locations we call sites. A user might have permission to do something (for example, edit a site's configuration) at one site but not another. Therefore, we now need to lookup permissions based on current user AND current site. Also, a certain user's permissions may be very specific to themselves ie. no other user's permissions are exactly the same as another user's. Therefore we need a security model that's more permissions based rather than role based.
What's the best way to design a new permissions model that can meet these requirements? I want to make sure that it's easy to implement the checking in the code (I don't want a million if statements sprinkled in our SetUIPermissions methods) and we don't want to have to update every user (400+ and counting) each time we add a new permission. Because of this last requirement I think we need to keep the idea of roles but possibly add/remove exceptions for particular permissions for specific users.
Any ideas?
You're on the right track with the roles and permissions. It's a relatively common solution to have a role refer to a set of "default" permissions; by having a user have a role and a set of permissions, you allow for the role to be overridden by the set of permissions specifically granted / revoked for that user. This gives reasonable flexibility and granularity, and supports your situation of adding new permissions (in the role) without needing to touch every user.