I’m working on a project that will require the provisioning of a SharePoint site collection for each customer that subscribes to my service. Each newly provisioned customer site must have a vanity URL. With SharePoint, the only way to scale to hundreds or thousands of customers with vanity URLs is to use Host Named Site Collections (HSNC).
Host Named Site Collections (HNSC) in SharePoint allow you to create a vanity URL (or vanity domain name) to a site collection. For example, you can create a new host named site collection as “http://customer1.contoso.com” instead of “http://www.contoso.com/sites/customer1”. For more information on SharePoint HNSC see the following articles: Plan for host-named site collections, What Every SharePoint Admin Needs to Know About Host Named Site Collections, Host Named Site Collections (HNSC) for SharePoint 2010 Architects
One of the key requirements for our business is that customer user accounts for each site are to be managed by each user and NOT by us. Eliminating the need to manage accounts for the many users is an obvious huge benefit in reducing operational management.
Eliminating account management can be achieved by using SharePoint’s claims based authentication in combination with a 3rd party claims based federated authentication service. Azure Access Control Service (ACS) provides such a capability.
ACS provides claims based federated authentication using different identity providers such as Facebook, Windows Live, Google, Yahoo, etc. By configuring SharePoint with ACS, the service will allow users to sign in and access their SharePoint site using their own personal email account (as long as it’s from one of the accepted identity providers).
With SharePoint claims authentication and ACS, SharePoint security will work exactly the same way as if on-premise Active Directory accounts were used. Users responsible for managing access to their company’s site can add other users (i.e. their email addresses) to the relevant SharePoint groups.
If a user forgets their password, then it will be up to that user to recover/reset their password with their identity provider (e.g. Facebook, Windows Live, Google, etc). For example, if a user with a Windows Live account forgets their password, we don’t get the call to recover/reset it. The user will use the Windows Live service to change their password and then they can regain access to their SharePoint site.
To repeat, I want to use SharePoint Host Named Site Collections (HSNC) with Azure Access Control Service (ACS) so that: 1) Each customer can get their own vanity URL, and 2) Account management (e.g. password changes) is delegated to the customer’s users via use of a claims based federated authentication service.
My current understanding is that to work properly with ACS each SharePoint HNSC must be configured as a relying party (RP). A relying party (RP) “… is a web site or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority”. The external authority is ACS. The following logical diagram illustrate what works:
I have this working but it’s not what I want. IfI have a thousand customers sign up, I don’t want to have to create 1,000 relying party entries in the ACS configuration portal when all the customer sites are designed to authenticate in the same way using the same set of identity provider choices ((e.g. Facebook, Windows Live, Google, etc).
I want to only have a single RP configured in ACS to be used by all customer HNSCs for authentication. If, for example, the web application that hosts HNSCs is “http://www.contoso.com”, I only want to create a single ACS relying party for “http://www.contoso.com” configured for the same set of identity providers (e.g. Facebook, Windows Live, Google, etc) and to be used by all customer HNSCs. This is what I want:
Authentication fails if I try to use just a single ACS RP for all HNSCs. The federated authentication logic in the internals of SharePoint and Windows complains that the URL prefixes differ. For example, if there’s a customer HSNC with URL “http://customer1.contoso.com” and I try to use the single ACS RP for “http://www.contoso.com”, then the prefix “http://customer1” doesn’t match “http://www” and authentication fails. I can understand the obvious reason why authentication fails in this scenario. It’s a security risk to allow what appears to be a different web application (http://customer1…) to authenticate against the ACS RP which starts with “http://www…”.
So, to sum up, the challenge is that it doesn’t appear that SharePoint HNSC and ACS play nice together where you want to trust a single ACS RP for the business scenario, unless you go down the road of creating a ACS RP for each customer HNSC. I can do that but would like to avoid it. At this point, if anyone has any solutions, insight, pointers, I would appreciate the feedback.
Configuring SharePoint and ACS Configuration
If you’re interested in technical detail on how to configure ACS with SharePoint, refer to one or more existing articles out there: search for SharePoint and Access Control Service. I’ve referred to several of those articles which were very helpful in understanding and configuring ACS and SharePoint.