In my case, I want to create a new administration user who has full privileges, such as add/modify/delete entities and properties, on in a certain DN (and maybe its sub). According to the document, in the table of "Directory Data Administration", it seems that I can create it who can "Access to read and write to others' entries", but I don't know how to. Could anyone help please?
I found the solution is related to ACI. Thus, I can create a new admin entity in subtree of cn=config, and then add some aci properties to the certain DN which I want limit the admin to. It seems work to my case.
Related
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.
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.
I am currently setting up a small server with several applications. Since no Active Directory etc is planned, but I do need a centralized user administration, I decided for LDAP since all applications are capable of authenticating against it.
I have already set up a domain "dc=example,dc=lan". It has two organizational Units. Groups and Users. My plan was, to create a posixGroup for every application, so that a user can be added to each group (if he/she was allowed to use this application).
The structure would then be (example):
for each group
cn=ejabberd,ou=groups,dc=example,dc=lan
where cn=ejabberd is of type "posixGroup"
and for users
cn=user1,ou=users,dc=example,dc=lan
where cn=user1 is of type "posixAccount"
Some, but not all, applications expect the "mail" attribute as login name. Some don't.
My problem is, that searching for users in ou=users is easy as 1,2,3 - searching in "cn=ejabberd,ou=groups,dc=example,dc=lan" is sheer driving me crazy since the users are not a "child" to this group but a "memberuid" attribute.
I have tried different filters and thought about another setup.. Just cannot think of anything different making sense right now.
Am I running down the wrong way, or maybe just blind to what's right in front of me?
I'd be glad for any finger pointing out a direction.
So here is, how I did it:
I created the following structure.
+dc=example,dc=com
+ou=groups
| +employees (PosixGroup)
| +service1 (GroupOfNames)
| +service2 (GroupOfNames)
+ou=users
| +user1 (User Account)
| +user2 (User Account)
etc..
Groups like "service1" and "service2" are of type "GroupOfNames". Furthermore I had to install the "memberOf"-Overlay so I could search for this exact attribute of a user.
This now gives me the possibility to tell each service to use a search filter that returns only the members of one special group, which will be granted access. For instance, ejabberd will use this filter:
"(&(objectClass=inetOrgPerson)(memberof=cn=ejabberd,ou=groups,dc=example,dc=com))"
Found these informations on the following website. Just take care to set the filter case sensitive! "memberOf" will not return any results, since the overlay in this example uses "memberof".
http://www.schenkels.nl/2013/03/how-to-setup-openldap-with-memberof-overlay-ubuntu-12-04/
I suggest you're on the wrong track. You don't want to authenticate by application, you just want to define overall roles that users can be in. The applications can then be defined to require certain role(s) per application funtion, web page, etc. As a limiting case, an application can be a role, but if you set out to define it that way you're overly limiting yourself.
To answer your immediate problem, you only have to search under the ou=Groups item for posixGroups which have memberUID={0} where {0} is the DN of the user. In other words the search filter is
(&(objectClass=posixGroup)(memberUID={0}))
Iterating those search results then gives you the DNs of all the groups of which he is a member.
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 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.