Hiding Permission Groups for Your WSS-Based Extranet

We’re using our hosted WSS site for our Internet site, our Intranet, and our Client Extranet.  This is a very cool use of WSS, IMHO.  Not only do we have all of the great content management capabilities for our external site, but we have the team-based capabilities which we can use to interact with our clients and amongst ourselves.

One of the tricky bits to this configuration is of course to get the permissions right.  Because WSS was built fundamentally as a collaboration platform, your users often see things that you don’t really want them to.  One specific thing you probably don’t want to expose is the permission groups.  For instance, if you have a group called Clients – Client A, you probably don’t want the members of that group to know that the group Clients – Client B even exists, not to mention its membership.

The solution for this isn’t totally obvious.  By default, every user who has access to a site can also see the permission groups and users from that site.  Since permission groups are managed at the Site Collection level, that means that they can see all of the groups, not just the ones that have permissions on the current site.  Sure, you might say, just create separate Site Collections.  That’s one answer, but since we want to be able to enable collaboration not only between us and our clients, but potentially also amongst our clients (should they decide they want to be a part of that community), separate Site Collections would be limiting.  We want this all to work within one Site Collection.

Removing the People and Roles link on the Quick Launch hides the visible navigation, but any user who has spent any time with SharePoint is likely to know that the page lives at /_layouts/people.aspx.  (You will want to remove the People and Groups link, though, so that the users won’t get the unsightly

Error: Access Denied

error page.)  Never forget that obscurity isn’t security!

To clean this up, I created new roles called Read – No Browse User Information and Contribute – No Browse User Information.  (See this previous post about managing roles.)  These are copies of the Read and Contribute roles, but with Browse User Information removed:

We have a permission group called Clients, and I assigned the Read – No Browse User Information role to that group on the Extranet site.  Each client sub-site has a permission group like Client – Client A which is assigned the Contribute – No Browse User Information role.  Now the users can read or interact with all of the content, as appropriate, but they can’t “see” each other. 

If you do this, make sure that you make the change for any child sites which don’t inherit permissions as well!