views:

384

answers:

3

I have a requirement to lock down access to a SharePoint library: Only users that belong to all the groups associated with the library should have read access; others should not be allowed to read.

Let's say I have a document library that concerns three projects:

12345
13579
24680

I have users that belong to one or more projects:

Joe:   12345, 24680
Jane:  13579, 24680
Jim:   24680
Harry: 12345, 13579, 24680

I need to restrict access to this library to only users who belong to ALL projects. I.e., only Harry should have access; the others should be denied. We'd use SharePoint groups named after each project to represent the 'belongs' relationship.

Edited with more detail:

We plan to create the doc lib and set up the initial security via a workflow. However, more projects may be associated with the doclib after it's created, based on info entered in a form, and people can get moved in and out of project groups by admins (e.g. for promotions, new hires....)

For now, if a form submission adds a new project after inital setup, an admin will probably create a new group if necessary, and assign it access to the doclib. Eventually, we'd do this in a workflow.

Currently, we're writing code to assign the initial security state for the site:

We scan a list of projects entered by a user into a form, create new project groups if necessary, create a site and a couple of doclibs, break role inheritance and assign our groups read access to the doclib. We add some users to each project group.

At this point, any of those users have read access. What we don't know how to do is restrict access to only users who are members of all the groups.

+1  A: 

You could set your document library to BreakRoleInheritance and set permissions to your items individually.

This is a example:

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite site = new SPSite("http://..."))
    {
        using (SPWeb web = site.OpenWeb())
        {
            web.AllowUnsafeUpdates = true;
            SPRoleType role = SPRoleType.Reader;
            SPRoleAssignment assignment = 
                new SPRoleAssignment(web.Groups["groupname"]);
            assignment.RoleDefinitionBindings.Add(
                web.RoleDefinitions.GetByType(role));

            SPList list = web.Lists["name"];
            SPListItemCollection items = list.GetItems(new SPQuery());
            foreach (SPListItem item in items)
            {
                if (!item.HasUniqueRoleAssignments)
                     item.BreakRoleInheritance(false);

                while (item.RoleAssignments.Count != 0) // remove all
                       item.RoleAssignments.Remove(
                       item.RoleAssignments.Count - 1);

                item.RoleAssignments.Add(assignment);
            }
        }
    }
});
Rubens Farias
Yes, we plan to break the inheritance. I'm asking HOW to set the permissions. We can't do it manually -- we have to do it programatically at a certain point in a workflow. I'm hoping for a declarative way to do it, so that I simply add users to various groups, and set the project's DocLib to various groups. This basically works for the OR relationship: we break inheritance and set read access on the DocLib to members of group 1, 2 or 3, and if a user is a member of 1, 2 or 3 then the system lets them in. How would we set read access on the DocLib to members of groups 1, 2 AND 3?
Val
A: 

The only way I can think of achieving this is to create a custom timer job that updates your document library every day by deleting all the rights, and then adding them again overnight. That would mean that people who join those projects will have to wait 1 day to get acces. You would just create a collection of all the users of group1, and check for each one if they exist in group 2, 3, ... and if they don't remove them from the collection.

KoenVosters
+3  A: 

You've made it hard on yourself.. SharePoint nor AD works this way, I'd go back to the drawing board because this will only cause pain ;)

I would decouple management of groups and their assignment to document libraries and sync rights throughout SharePoint like Koen mentioned. e.g. you manage group membership separate from the groups you use to connect them to document libraries. Then you need a process to enumerate over these separate groups and assign the users in there to the document libraries individually according to your business rules. Brittle at best.

ArjanP
you're right, we were making it hard on ourselves. We're changing the requirements...
Val

related questions