I have a discussion list and need to provide contribute access only to this list for all users with read access(i.e visitors). Basically, all visitors should be able to submit their comments in discussion list, but at same time no contribute access on any other lists of the child site. How can I do this without breaking the permissions inheritance from top level site??
Any workaround/ideas are appreciated..
"without breaking the permissions inheritance from top level site" <-- not possible!
Sharepoint's permission model is based on inheritance. If you want different permissions for one particular list, different from the rest of your site - you will need to break permission inheritance (hence the name inheritance).
Any reason why you don't want to break inheritance?
Related
I'm programming a new application with many users, a few roles and specific permissions for those roles. For that I want to create the following tables:
Users (ID,Login, password,..)
Roles(ID,Rolename)
User_Roles(User_ID, Role_ID)
Permissions(ID,PermissionName)
Permission_Roles(Permission_ID, Role_ID)
My idea was to build a function, which allows to check if a user has a specific permission to access a form. I would do that by creating Permissions/Rules like 'canReadFormX', 'canEditFormX' which would allow me to use one main function to check and perfom those specific rules and a function per form to call it.
Is that a way to go (or rather did I understand everything correctly regarding RBAC) or is that just far to complicated? Any advise is very appreciated!
It seems fair to me, and similar to what we have already set, for the first 3 tables.
You then have to solve the 'action' problem, ie to distribute permissions to use your appl's actions. I am not sure that your 'Permissions' proposal will cover all the situations, as you have to deal with 2 major categories of actions:
The 'Open form' actions, that you already have identified: you effectively have to define 2 levels of authorisation for each form: the 'view' right, and the 'update' right.
All other actions, such as form specific buttons or menus, that will allow you to run a specific action other than just opening a form (execute a report, make a specific calculation, automatically import or update data, etc).
One solution/My advice is to maintain 2 tables for this:
A 'Forms' table
An 'Actions' table
And the corresponding link tables:
A 'Form_Role' table
An 'Action_Role' table
With such a configuration, you are fully covered. You can even decide which role has the right to see a specific report on a specific form, as long as the corresponding action is accessed through a specific control or menu on the form.
Both Forms and Actions tables are very interesting as they both participate in your application metamodel...
EDIT: By the way, if you are on a domain, you can use user's domain credentials to control his\her access rights to your system. In this case you do not need to store a password in your RBAC system.
I've been struggling with this off and on for months, and it may be non-trivial to answer.
What is the easiest way to limit public access to an item and its subitems to members of a single role? (Editors still need to be able to edit the item.)
e.g. There's a role, extranet/clubmember, and items,
- Clubhouse
| - Items
| - Inside
| - Clubhouse
And I want extranet/clubmember members to be able to read the items and subitems, sitecore/* members (Or, say, sitecore/editor) to have edit access, and everyone else (in default and extranet domains) to be denied.
Second, does this solution still work with a custom role and membership providers for extranet? Why or why not, or what methods do I need to implement? I recall from earlier experiments that my custom role provider seems to affect Inheritance permissions in particular.
Have you tried the following:
uncheck Inherit for Everyone (the global one) to Clubhouse root
explicitly allow Read for extranet\clubmember to Clubhouse root
explicitly allow Read/Write for sitecore\Everyone to Clubhouse root
Explicit assignments always win. So, that scheme should have the effect you expect.
How do I create a different users category? (more restrictive - with view only properties)?
How do I create a View - only for this category of users?
I need to group some users into a view only category and then assign only ONE view to this group, so they can not see everything that is in my list.
SharePoint, so far, does not give the option to restrict access at cell level so I need to go around this and create a view for this group, with the condition that all that they can see is this View (and they should not be able to add columns to this view).
Thanks.
Considering that you want to restrict the List View to only specific set of users. You have the following options
Doing it in the SharePoint UI but not suitable if you have lots of item and you want to do it for a SharePoint Group.
Open Source - CodePlex Good one I have tried it - It has got what exactly you want Column level restriction
Third Party in case if you feel to spend $ - Seriously I didn't try this tool.
Another Option to do it in SharePoint UI - Quick solution but - Wont prevent user from creating their Own Views.
As MSDN states, then WriteSecurity has 1 of 3 states possible:
1 — All users can modify all items.
2 — Users can modify only items that
they create.
4 — Users cannot modify any list
item.
But if I want behavour nr. 2 plus users can modify items that are assigned to them? Well if I grant a user full permissions (put in owners group) for list, then those can edit any item (not good). So why wouldn't it work by setting item level permission "full control" just for AssignedTo user (good)? I did, but that didn't help - access denied.
I want exactly the functionality as stated in question "Automatically set list item permission, after new item is created", quoting:
Every users (Supervisor and team members) can see any tasks.
Supervisors can edit any tasks
Team members can only edit their own tasks (tasks that were assigned to them, or created by them)
but although answer has been accepted, the solution does not provide a way for users to edit items assigned to them or items created by user.
Help is appreciated, thank You!
Your only way to do this is using Item-Based Permissions. E.g. have a Workflow or Event Handler change the permission on each file/object based on your requirements.
The solution you quote from the other task is simply setting 2 for SPList.WriteSecurity which still doesn't give users the possibility to edit something they have not created, but were assigned to - in this case you will need to give these users permission, e.g. by listening on the "Assigned To" field with an Event Handler (OnItemUpdated) and give the respective person the needed permission.
Furthermore the solution talks about just setting higher permissions for the users who should always be able to edit items (managers), which is a solution, but you do not have the granularity you usually want in situations like these.
I'm searching for the best way to handle view-level authorization (where you hide markup based on a user's roles).
The typical way to do this is with the Acegi Security authz tag, as follows:
<authz:authorize ifAnyGranted="ROLE_FOO, ROLE_BAR, ROLE_BLAH">
<!-- protected content here -->
</authz:authorize>
The problem with that approach is that it quickly gets messy. For one, you either hard code the user roles as above or you create a constants file that duplicates them all. Second, there's no way with the current scheme to group roles logically. I suppose one solution is to define a separate role for each UI element, but then the declarative method level security on the business methods would need to be updated for each UI element (would that be a good thing?). This would also cause a proliferation of user roles! The use cases for my application actually mandate very few, e.g., Manager, Manager Supervisor, Super User (can do everything), Read Only, etc.
The solution that comes to mind is to treat the authorizable UI elements similar to message resources. That is, define a series of "authorization points" in a properties file similar to a MessageResources file. My initial thoughts are as follows:
com.lingoswap.home.editUserNameButton.ifAnyGranted=ROLE_FOO, ROLE_BAR, ROLE_BLAH
com.lingoswap.home.deleteAccountButton.ifNotGranted=ROLE_NOOB
com.lingoswap.home.deleteAccountButton.ifAnyGranted=ROLE_ADMIN
...
To protect content on the home page, we would then use a different protected tag (one that borrowed heavily from the original authz, possibly a sub class):
<security:protect component="com.lingoswap.home.editUserNameButton">
<!-- edit user name button -->
</security:protect>
<security:protect component="com.lingoswap.deleteAccountButton">
<!-- show the awesome delete account button that's not for nincompoops -->
</security:protect>
The advantages to this approach are the following:
Easy to test - we can write unit tests that verify the user-role-to-ui-element mappings (of course, it still has to be used on JSPs)
Error checking at runtime (and test time) - if a user role is misspelled in the .properties file, we can throw an Exception
Easy to tweak user roles - the requirements team continually refines the user roles; it'd be nice to change them all in one central location
Easy to understand - we can at a glance view the user role permissions for the entire application
Can be done DRYly (using property Spring placeholders to group related roles, e.g., ${readOnlyGroup} can be used in the properties file instead of the actual role names
The disadvantages seem to be:
Moderate complexity
Others??
Thanks for your advice.
Regards,
LES2
I did somethig similar to the second approach. And because I wanted all my security definitions in one place I implemented my own objectDefinitionSource for the FilterSecurityInterceptor.