Best practices for building a SharePoint Extranet

Question

What are the best practices when it comes to building a SharePoint Extranet? Any good resources out there?

One question that I am particularly looking for some thoughts on is how to best create a water-proof separation between different customers on an Extranet. My experience tells me that it would be best to create a new site collection for each customer. But others in our project argue for a single site collection with a sub-site for each customer. Each sub-site will of course have separate permissions and navigation. They argue for one site collection in order to be able to roll-up shared content with the CQWP.

But in my world a shared site collection is, security wise, just too dangerous a design. The risk that one customer by accident gets access to the sub-site of another customer is just too big.

What is the best practice on this one?

Answer 1

Have you considered using Tenants?

http://www.harbar.net/articles/sp2010mt1.aspx

http://blogs.msdn.com/b/russmax/archive/2010/04/02/sharepoint-2010-multi-tenant-hosting-part-1.aspx

http://blogs.msdn.com/b/russmax/archive/2010/04/03/sharepoint-2010-multi-tenant-hosting-part-2-configuring.aspx

EDIT: As usual when we are talking SharePoint best practices, the answer is "it depends".

If security is a big issue, this speaks for seperate Site collections. You could still roll up data between SC's using search web parts.

Answer 2

We have had an extranet built on SharePoint since 2006 and we made the initial decision to put each client into their own site collection. I know that's a lot of site collections and for us, since we put each site collection in it's on databases, it's a lot of databases. But we feel like that decision was the correct one. It also leaves the most oportunity for growth and meeting the needs of the client.

FYI, here's a link to a case study done by Microsoft on one of our clients that uses our extranet: http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000003041

Answer 3

Definitely don't put everything in a single site collection, and if you really want people not to even know the other users and sites exist, you'll probably want to look in to the peoplepicker-onlysearchwithinsitecollection property. A lot of the other options depend on where you want to store your users (i.e. using Windows auth, FBA, etc). It's hard to get too specific without a little bit more detail.

Also, aren't you kind of a search guru? :) I would think you'd be able to find search-based solutions for most of the cross-site "rollup" scenarios.

Answer 4

We made the mistake of putting everything into a single site collection for one type of external program we run. The biggest problem we found was that when doing a security review, it was more difficult to assess where security inheritance was in place and where it was broken. As these types of extranet are ongoing, it's easier to just deal with the problem than try to fix it.

For a new type of program, we're looking for a greater level of customisation and are taking advantage of what site collections provide. Features such as custom navigation and security (clearly distinctive from other site collections), own branding, its own search scope and the ability to more easily deploy the whole site collection to the live site from dev and QA.

Answer 5

We usually go with separate site collections in cases like this also. If the site is on SharePoint Foundation, you would not be able to search across site collections, right? I would think that is a nice added security feature in this case as well. You could always have one site collection that is accessible by all customers for common content, then link to the individual site collections for customer-specific things.