I am developing a POC (SahrePoint 2010) where I can demonstrate that the users can be granted certain permissions on a list for a Date range (for example contribute access for a selected week). I will be breaking permission inheritance and create unique permissions for a list.
I would like the permissions to be revoked automatically after the expiry date. Also, I would like to do this using the Manage Permissions list (_layouts/user.aspx) so that I don't have to maintain a separate list.
I have a couple of questions regarding this:
1. I assume that the custom permissions for any list must be stored n some list. How can get to know in which list the permissions are getting stored?
2. If at all I get to know in which list the permissions are getting stored, will I be able to add columns to that particular list?
I hope that the question is clear.
Permissions are not stored in any list. Rather, every securable object (including sites, lists, folders, and items) has a Role Assignments property that indicates what groups/users currently have access, and what their permissions are (if not inherited).
See the SPRoleAssignment class documentation for more information.
Note that the User Information list is not a "Manage Permissions" list; it stores profile information about users who access the site, but does not store any permission-related information. Further, it's not a typical list at all, in that it does not show up in the SPWeb.Lists collection for a subsite, and its fields are automatically populated by SharePoint's User Profile Service. While you could potentially add more columns to it, you'd be better off using a separate list to store and track your permission information instead of contaminating the site collection user info list.
To have permission changes take place based on an expiry date, you'll need to implement a time-based solution that runs on a regular basis to see if any changes need to be made, such as a custom timer job, a custom site workflow that runs on a schedule, or a Windows scheduled task.
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?
Let's think of a simple REST-based web service to store and retrieve JSON objects. Without any authentication, every user can access any data.
Now let's add usage of JWTs to authenticate users. Of course, since we are not doing authorization, still every user can access anything, but at least now we know who accesses what.
Next step: When storing an object, save the user's sub claim with the object, and verify that the user's sub claim matches the one of the requested object, and if so, deliver it. Now we have authorization on a per-user basis. So far, so easy.
Now let's add the possibility to let users share objects with other users. For the sake of simplicity, say, we want to have predefined groups (i.e., roles) and we want to let the user choose which group (role) has access to the objects they create. This is still easy, as you have a predefined list of groups, so you can let the user choose one or more, and attach them to the object. Additionally, the identity provider needs to be configured in a way that it put a groups claim into every user's token, so we can match them. As we can already see from the length of this paragraph, things become more complex.
Question 1: Am I right so far, that handling "static" groups this way it the way to go?
Now, let's give the users the opportunity to create groups on their own. This is still not complicated, but how do we make the identity provider use the dynamically created groups? For sure we do not want to make an administrator update the identity provider's configuration every day ;-).
Question 2: How do we handle dynamically created groups?
Now, finally, let's forget about groups, and let's say, that we want to allow the users to be able to simply share their objects with other users. This should be configurable for every object individually. How do we do this? Do we save a list of users on the object? If so, what exactly do we save? The sub claim? If so, how does the owner user know the appropriate values? Or ...?
And: Supposed the users want to put their friends dynamically into dynamically generated circles, how would we do that?
Question 3: How do tokens and dynamically created groups with dynamically assigned users work with each other?
In my opinion the tokens should only include identity-information(-claims) you'll need to identify the user on your ressource server or that wont change when refreshing, since you wouldn't want your user (or your app in place) to have to refresh his access tokens each and every time his permissions change (since access tokens grant access for a specific amount of time you wouldn't want your user to have access to certain ressources that he's lost the access rights to since his last token refresh by not refreshing the token and simply using the old one either). The more security related information you append to your token, the more vulnerability you may add to your system (depending on your token lifetime).
Stating so, I would (and always do) identify the users roles or groups by his user-id (which is included in the jwt-token) on the ressource server. To achieve this, I always attach the users identity-information to the current request on my ressource server and attach "dynamic"-claims like the users role or group to the identity.
By adding only the identity information I need to identify the user and the user's rights on my ressource server, I tend to use my identity providers across multiple applications without handling application scope on the identity provider, so I can use the exact same access token for multiple independent ressource servers.
I'm working on creating an administrative interface that allows managing users in groups in Active Directory.
I would like to only show groups to the active user if the user actually has the rights to add or remove other users within those groups, but I'm not sure at this point, how to determine which people can modify the groups, or whether the current person has access to modify a specific group.
I suppose the application can find out after the user tries and we get an access error, but I don't like to use error trapping as a way of determining if some feature is available and I would prefer not to tempt the users with a list of groups they can't control.
If possible, please supply an answer that targets vb.net 3.5 using System.DirectoryServices.AccountManagement as that is the environment that I am currently working within. I can translate from C# if necessary.
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.
I have set up an external content type with a column that contains Active Directory accounts to map each record to a user. Now I want users to only see those records in the list where the AD-account entry matches the current user's credentials.
So I tried the following approach, and succeeded in creating a user context filter on the ReadItem/create/update/delete operations. However, on the ReadList operation there is no option for it, the wizard has different filter options.
The result is that the current user can see all items in the external list, but can only open those tagged with his account, so the filter definitely works. However having the filter only on items and not on the whole list is useless (items that cannot be opened will confuse the user, a list view might expose the data anyway etc.).
I tried to filter this list with the Current User webpart, which gives us the desired result, but the list itself is of course still sitting in the background and can be opened via URL.
How can I get the user context filter applied on ReadList? And if that is not possible, where and how do you implement such a filter?
Export the BDC Metadata Model from SharePoint Designer and edit it by hand to include the UserContext filter. Then reimport the model through the BDC Service Application in Central Administration.