2013/11/12: This post is deprecated, please take a look at our revised, suggested configuration.
As we all know too well, Microsoft products are best suited to work with… other Microsoft products. The best example is probably how Active Directory plays a pivotal role in authentication with most Microsoft products, if not all. Of course, SharePoint is no exception to the rule.
However, while Active Directory works great for internal users, it’s not as convenient when it comes to dealing with external users, such as partners, customers, contractors, vendors, community users… Oh sure, Microsoft have solutions to this issue too, such as Active Directory Federation Services (commonly known as ADFS), but those solutions, though ideal and very secure, typically tend to increase the deployment complexity, are costly, and sometimes merely impractical (imagine if you dealt with 100 partners and had to get their approval to set up a trust between their Active Directory and yours… good luck with that!).
That’s why a few alternative identity management solutions have emerged, especially in the SharePoint market, where external collaboration is a growing trend. Those solutions, commonly referred to as “FBA solutions” (for Forms Based Authentication solutions), leverage the ASP.NET Membership Provider interface that SharePoint has been supporting since the 2007 release and that basically allows you to authenticate a user against any user repository you might think of, be it an LDAP directory, a SQL Server database, a SharePoint list, an XML file or even a bare bone text file (to be honest, some of those options are only possible if you write a custom membership provider, but that’s outside the scope of this article).
All of that is fine and you can quickly set up such an FBA-powered SharePoint site in a development or test environment, especially if you use Extradium for SharePoint
But when it comes to production deployments, things get a little more complicated, most notably in the area of network topologies. That’s a topic we discussed in our How to deploy SharePoint to Extranet Users presentation and that is masterfully explained in a detailed Microsoft Extranet topologies for SharePoint 2010 diagram. We’re not going to discuss here the pros and cons of the Edge firewall, back-to-back perimeter and split back-to-back topologies, but suffice it to say that pretty much all of them include a firewall product. Of course, in those diagrams, the firewall component is Microsoft ForeFront UAG, but who could blame Microsoft for advertising its own products? We all do
Of course, we strongly recommend our customers to deploy firewalls in front of the SharePoint external-facing infrastructure, and most of them use traditional firewall products that only inspect, filter and redirect the traffic to the appropriate web servers, usually located in a DMZ (but not always).
What’s special about ForeFront UAG (as well as ForeFront TMG and their ancestor, ISA Server) is that it’s an “intelligent” firewall, insofar as it needs to be aware of and validate user credentials BEFORE giving access to the external-facing site (in our case, a SharePoint site).
However, as we may expect, ForeFront UAG primarily integrates with Active Directory and ADFS (as well as other well-known directory services), but has no integration whatsoever with Microsoft’s own ASP.NET Membership infrastructure, let alone with SharePoint set up with Forms-Based Authentication.
While this seems to be a recurring question, the information available on the internet is surprisingly scarce. In your search of a solution, you might have found Dror Melovany’s blog post on SSO to SharePoint 2010 through UAG when using two authentication schemas, but as you go into the details of his clever solution, you will soon realize that it only works because external users authenticate against Active Directory (through the SharePoint Server’s FBA Ldap Membership provider – which is not available in SharePoint Foundation, btw). The “trick” is that they authenticate on UAG with the standard UAG Active Directory authentication provider and then the credentials they supplied are in turn inserted into SharePoint’s login screen for SSO purposes. But that blog post would be of no help if your external users were stored, say, in a SQL database, which is the case of Extradium users.
The only online blog that hinted us to our current solution is Andy Hecker’s blog, who makes a superb job at describing in every single detail the process of setting up and customizing UAG to support FBA with a SQL Server database. We have to give him huge credit for his research and we definitely recommend reading his two blog posts,How to Authenticate users against SQL Server and Enable SSO by passing user credentials to formular based Web Applications, mostly because we won’t get into as much detail as he will.
Also, a working knowledge of ForeFront UAG is a prerequisite, as well as a good understanding of the publication of a SharePoint 2010 site through ForeFront UAG. There is a good tutorial video on this topic, and we strongly recommend you to first make sure that your SharePoint site is published through UAG with Active Directory authentication. Actually, we will consider this an assumption for the rest of this blog, so please do not post comments on how to publish SharePoint to external users through UAG
As Andy clearly delineates in his blog posts, there are two major challenges when integrating SharePoint FBA with ForeFront UAG:
- Authentication: how do I validate the user credentials against the user repository used by my SharePoint FBA site?
- Single Sign On (SSO): how do I seamlessly pass those credentials to SharePoint once the user has been properly authenticated by UAG and thus don’t require her to enter her credentials on the SharePoint sign in page again?
Where Andy’s solution falls a bit short is that it’s tied to the particular structure of the SharePoint FBA’s user repository (in his case, a standard ASP.NET database), and won’t enforce the logic of the membership provider (for instance, locking out a user after X number of invalid login attempts, or checking whether the user is enabled…). Also, his script includes a connection string with a User ID and Password in clear text, and his SQL command seems to assume that the password are stored in clear-text mode in the SQL database (unless I’m wrong). Overall, it didn’t seem like a very practical solution to suggest to our customers, as it would probably raise too many eyebrows and generate too many troubleshooting sessions.
We strived to find a more generic solution, and we’re happy to announce that we found one! That solution relies on SharePoint’s not-so-well-known Authentication.asmx web service, which allows UAG to rely on SharePoint’s FBA Membership Provider, whichever it might be, and to enforce the specific logic of that membership provider.
Let’s go to the trenches now and see how to practically install our solution in your UAG environment:
- First of all, you will need to download Extradium for SharePoint (you might have to first register).
Next, install Extradium in your SharePoint environment
- Navigate to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\XtrashareAdmin folder and grab the Extradium_UAG.zip archive.
- Move and unzip Extradium_UAG.zip on your UAG server. The structure of the unzipped folder follows the exact same structure as the UAG product, starting from the UAG installation folder (usually C:\Program Files\Microsoft Forefront Unified Access Gateway).
Copy the Extradium.inc file from the von\InternalSite\inc\CustomUpdate folder to the corresponding UAG folder (C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate).
This file is responsible for authenticating the user on the UAG login screen and calls the Authentication.asmx web service.
Edit the Extradium.inc file and online 22 replace the following highlighted value with the url of the SharePoint zone where FBA will be enabled:
strSharePointFBAWebAppUrl = “https://extranet.company.com“
Copy the FormLogin.xml file from the von\Conf\WizardDefaults\FormLogin\CustomUpdate folder to the corresponding UAG folder (C:\Program Files\Microsoft Forefront Unified Access Gateway \von\Conf\WizardDefaults\FormLogin\CustomUpdate)
Copy the FormLoginDataDefinitions.xml file from the von\Conf folder to the corresponding UAG folder (C:\Program Files\Microsoft Forefront Unified Access Gateway \von\Conf). Alternatively, if you already customized this file, you can copy the section that starts with <SCRIPT name=”ExtradiumFBA”> from our FormLoginDataDefinitions.xml file and paste it into your already customized FormLoginDataDefinitions.xml file.
Those 2 files (FormLogin.xml and FormLoginDataDefinitions.xml) are responsible for the Single Sign On. Note that they work both with the Extradium Sign In page (/_layouts/exs/default.aspx) and the default SharePoint Forms Sign In page (/_forms/default.aspx). However, in a mixed authentication scenario (where both Windows and FBA authentication schemes are enabled on the same zone), the user will first have to select her authentication method (Windows or Forms). Once Forms is selected, the SSO script will be triggered and the user will be seamlessly redirected to the SharePoint site.
- Next, open the ForeFront UAG Management console and select the trunk through which the SharePoint Extranet site will be available
In the Trunk Configuration section, press the Configure button:
Select the Authentication tab and press the Add button:
In the Authentication and Authorization Servers window, press the Add button:
In the Add Authentication Server window, select Other and type Extradium in the Server name text box:
Note: the “Extradium ” server name MUST match the name of the Extradium .inc file as mentioned in point #5 above, so if you want to pick another name (which will appear in the UAG login screen), you should rename the Extradium .inc file accordingly.
Press OK. In the Authentication and Authorization Servers window, select Extradium and press Select:
- Press Close and OK to close all the windows and go back to the main trunk screen.
In the Applications section, press Add :
Press Next and in the following window, select Other Web Application (portal hostname) and pressNext:
In Step 3 – Select EndPoint Policies, adjust the policies as shown below and press Next.
- In Step 4, select the option that matches your SharePoint farm deployment (in the next screens, we assume that we chose the first option – Configure an application server) and press Next.
In Step 5 – Web Servers, configure the internal Url of your SharePoint zone (where FBA is enabled), its HTTP and HTTPS ports and press Next:
In Step 6 – Authentication, check Use SSO, press the Add button, select the Extradium Authentication Server, and press the Select button. In Select authentication method, select Both and press Next:
- In Step 7, adjust the application’s parameters and press Next.
- In Step 8 – Authorization, leave Authorize all users selected and press Next.
- Press the Finish button.
Back in the UAG Management Console, press the Activate button in the top navigation bar (as shown below):
- This launches the activation wizard. Once the activation wizard has completed, you can test UAG again.
The login page of UAG should now look like in the following screenshot. Enter the credentials of an Extradium user (for instance, the admin user) and press the Log On button:
The home page of UAG now displays the SharePoint Extranet application:
After selecting the SharePoint Extranet link, the following page should briefly appear (this is where the Single Sign On is happening):
Last, the home page of the SharePoint Extranet should appear! (below is a screenshot when the portal is launched inside the UAG page).
This was a fairly long post, but I hope you found it useful.
Once again, to get those UAG scripts, you must download Extradium for SharePoint, install it on a SharePoint server and grab the scripts from the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\XtrashareAdmin folder.
As always, your comments are welcome!by