We want a policy whereby permissions must be managed through sharepoint groups. We want to allow site owners to add and remove users from groups in order to manage their permissions to resources, but we don't want them to be able to create the groups or to add user's explicitely to the resource. Is this possible? I don't see any permissions that relate to restricting explicit access to a resource as opposed to access via a group, but I could be overlooking something.
No, this is not possible out of the box. Either a user is able to manage permissions or not, there is no more granular settings to only allow managing in groups.
Unfortunately there also isn't an event receiver you could use e.g. PermissionAdded or PermissionModified, so the only way for you to check these things would be to write a timer job which checks every X minutes whether anything has changed you didn't want to change. Or another possibility is to not allow users to manage permissions, but write your own permission manager which only allows working with groups. Then you could use RunWithElevatedPriviliges to perform your actions.
Related
Hi i have a group system and i'd like to add some security to it.
Users can belong to multiple groups and id like to know the best way to authorize people to see the groups only if they are in it. If they aren't i want to redirect them to a another page, which is different according to the group.
For now i created a service but i have to use it in every controller...
I've heard of multiple things but not sure if they are appropriate for my situation.
Thanks for your help
There are several different ways to do this depending on the approach/complexity. Here are a few:
1) Use Symfony ACLS. When a user is added to a particular group, you can use the symfony ACL system to grant them view access to that group, and then later check isGranted() against that group to see if they have view permissions.
2) Create a custom voter
http://symfony.com/doc/current/cookbook/security/voters.html#creating-a-custom-voter
3) If the number of groups is limited in number, you could even use Doctrine query filters to automatically add a where clause to all queries where the group_id is in a list of allowed groups for that user. You can bypass this for all admin users. http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html
I'm developing an app using Parse.com for BaaS. Aside from regular security checks, it's my understanding/philosophy that part of security is to assume someone HAS broken in, and then limit the amount they can access/delete/mess up.
One way I'd like to do this is to have a per-user rate limit on certain API requests. I can imagine a sort of naive method where I keep a list of who has accessed recently and when, and check that list before allowing a request of that type to go through (I'm thinking beforeSave for various custom classes).
Is there a better, ideally built-in way?
Though Parse.com doesn't have options for configuring this, parse claims that they keep track of suspicious activities and attempt for DDoS attacks are monitored. But not sure to what extend this is possible, because this specific problem is scenario wise relevant/irrelevant.
You dont have an option to do user level rate limit, but they will report any suspicious activities found like redundant hits from same device.
As given in the Parse docs here, They support two levels of permissions, Class level (via Data browser) & Object level (using ACLs)
Configuring class-level permissions
Parse lets you specify what operations are allowed per class. This
lets you restrict the ways in which clients can access or modify your
classes. To change these settings, go to the Data Browser, select a
class, open the "More" dropdown, and click the "Set permissions" item.
Class level permissions is a manual way of giving access to specific users or roles on a class.
In your case, you might probably need object level permissions based on Access Control Lists(ACL).
Access Control Lists
The idea behind an ACL is that each object has a list of users and roles along with what permissions that user or
role has. A user needs read permissions (or must belong to a role that
has read permissions) in order to retrieve an object's data, and a
user needs write permissions (or must belong to a role that has write
permissions) in order to update or delete that object
Create a new role and add list of users to that role who can access. Then set an ACL like this on the other objects.
{ "role:YourRoleName":{"read":true, "write" : true}}
You can now dynamically add or remove users in that role without updating individual objects.
After reading http://en.wikipedia.org/wiki/Role-based_access_control and seeing the way people are building authorization/access control, this question came to my mind "Why we are checking roles of users when checking if they are permitted to do X rather than checking their permissions?"
This is what I understood, Users have Roles, Roles have permission and this is how a user can have permissions (A user cannot explicitly have permissions assigned to it, it gets its permission by having roles)
And I think it makes sense to check for a permission like "AddUser" when processing a request for adding a user but in .Net library and also in a lot of examples in RBAC we see that they check for Roles. Like they check if the user is in the role of Administrators rather than checking if he/she has the permission "AddUser".
Why? It kind of makes more sense to me to check for permissions.
Can someone please illuminate me here?
Thanks
You are correct - checking for roles in applications instead of permissions is not Role-Based Access Control. Spring security and many other prominent access control mechanisms propagate this security anti-pattern. For correct RBAC usage - perform permission checks in your policy enforcement logic.
If we simplify the RBAC system, RBAC is a method of restricting access to 'some sources or applications or some features of applications' based on rights of users of organization. Here, restrictions can be by means of multiple permissions, those are created by administrator to restrict access, and these permissions collectively represents a role, which will be assigned to user.
You might be partially true for your case :)
But consider a case of complex application, where there are 200 permissions, and administrators need to define few set of permissions to represent specific behavior via role, which will create some complex kind of customization and re presentation of the form for that user.
Here it might be required to check via ‘HasRole(‘SomeRole’)’ method to define exact behavior of user.
So, my answer would be, both methods are equally important in RBAC.
1) HasPermission(‘permissionName’)
2) HasRole(‘roleName’)
A good RBAC solution should provide both these methods. There are such tools available in the market, you can check for them.
I have a Sharepoint library that is too large for a central administrator to manage permissions on all items, so I want to designate a few other people who are able to allow or disallow read/write access for arbitrary items in the library to users or groups. However, I don't want to give those few people total "manage permissions" ability because I don't want them granting themselves or others full control or design permissions, etc.
Is there a way to grant "manage only read/write permission"? Or is there a better way of accomplishing what I'm trying to do?
Thanks!
This question pops up all the time, and I haven't been able to find an answer that immediately makes the asker happy.
I usually suggest that you stay away from item-level permissions, and instead create libraries pretty much mapping to groups. make a library for your Company X accountants, make a "Accountants at Company X" group, give them rights to that library. You should be able to trust them enough that they get to manage their own document library. If not, keeping the permissions on a per-library basis will make the workload much less, and the site administrator(s) can most likely handle the permissions on these libraries. If you want to make it easier for them, just create a formal workflow where a user can apply for access and an administrator grant it.
There are other ways, of course, but you're pointing at one of the major reasons you should stay away from item-level security. It's just a can of worms that you need to avoid opening if at all possible.
Maybe you can try the third party tool: SharePoint Permission Manager by SharePointBoost. You can search, analyze, manage and backup SharePoint users or group permissions on a centralized platform.
I don't think there is a specific permission that meets your needs for one site. I think your best option may be to split into sites or libraries you can allow others to manage for your central administrator.
Here's a related excerpt from the TechNet article, [Plan Permissions][1], that may help you more:
Users or groups are assigned a
permission level for a specific
securable object: site, list, library,
folder, document, or item. By default,
permissions for a list, library,
folder, document, or item are
inherited from the parent site or
parent list or library. However,
anyone assigned a permission level for
a particular securable object that
includes the Manage Permissions
permission can change the permissions
for that securable object. By default,
permissions are initially controlled
at the site level, with all lists and
libraries inheriting the site
permissions. Use list-level,
folder-level, and item-level
permissions to further control which
users can view or interact with the
site content. You can return to
inheriting permissions from a parent
list, the site as a whole, or a parent
site, at any time.
I would like to create a folder that users who do not have privileges to view the rest of the site can see. This user group would be granted access to the site, but I only want them to be able to view one particular page.
Is this possible to do without going to every single page and removing the new user group's access?
yeah, you should be able to create a new group and add the users to that list/subweb/whatever and just that. This is assuming that you didn't grant access to all users somewhere. If you did, then hopefully the default access is granted to a default user group (like sharepoint visitors) and you can alter that group to exclude the users you only want to access the limited part of the site.
If created correctly the new group shouldn't have access to the rest of the site.
If you are getting thrown off by the fact that the user/group is listed as having "Limited Access" on the ACLs on, say, the parent site/web. That's just a placeholder SharePoint uses to make sure people have access to at least the bare minimum set of objects (e.g. theme and other UI files and the parent web itself) to get to the list or item you actually want them to have access to.
As long as the group only has access on a single list, you should have to worry about them having access to anything else.