<foreword>Please read this explanation of Forms Based Authentication (FBA) first if you are unfamiliar with how FBA works or is implemented. </foreword>
Achieving single sign-on capabilities using Forms Based Authentication is much easier than I had initially expected, yet it took awhile to find the exact settings required. To get FBA working in SharePoint click here for a good starter from the SharePoint team blog. I also used this article from MSDN as a reference for ultimately determining what settings were necessary in our environment.
Small back story for what we are doing. We have a SharePoint farm that has split authentication: Windows Integrated for users on the network at the office and FBA for users out in the field on the extranet. Separate from our SharePoint farm is a .Net web application to assist with password reset and registration. When the user logs in to SharePoint via FBA they are redirected to the external application if there is any problem with their account. We wanted to implement single sign-on between the applications so that a user wasn’t re-prompted for credentials after the redirect.
The general solution involved the following main items:
- Changes to both applications’ web.config files
- Configuring host headers for each app to be in the same domain lookup
- 1 line of code to read authentication cookie
So let’s review what was added to get this working starting with the web.config entries.
<system.web>
<authentication mode="Forms">
<forms name="nameOfCookie"
loginUrl="loginPage.aspx"
path="/"
domain="mydomain.com"
protection="All"/>
</authentication>
<machineKey validationKey="value" decryptionKey="value"
validation="value" decryption="value" />
</system.web>
For the web.config entries you’ll need to ensure that both apps are set to Forms authentication. Next specify a “name” value which will be used to identify your authentication cookie on the receiving application. By default this value is “.ASPXAUTH”. Specify the domain that each web application will be run under. Using host headers your site URLs might look like "site1.mydomain.com” and “site2.mydomain.com”. Specify protection=”All” so that the authentication cookie is encrypted using the machineKey value that you specify. Lastly provide identical machineKey entries on each web application so that both can read the authentication cookie provided by each other. I used a free random machine key generator in my development environment, but you’ll probably want your security team to handle generating and keeping track of keys for non-development environments.
The next step involved configuring each site to use host headers assigned to the same domain.
This article from TechNet gives a brief intro to get you started. As stated just above, I configured the web app URLs to appear as “site1.mydomain.com” and “site2.mydomain.com” to match my entries in the web.config.
Lastly is the code required to read the authentication cookie. If you read the
explanation article linked in the foreword above you’ll read that after logging in using forms authentication, the authentication cookie containing the currently authenticated user (along with other data) is passed along with responses back to the server. Due to this fact, on the receiving page in the other web application we can decrypt the cookie and read who is currently authentication even though they never logged in again to the the other application. Here is the code to explicitly reference that cookie.
string loggedInUser = FormsAuthentication.Decrypt(Request.Cookies.Get("cookieName").Value).Name
And that wraps up the changes to my web apps to allow single sign-on for forms based authentication. If your web applications are SSL enabled I believe there are a few additional settings you’ll need, but they should be covered in the links I provided. I hope this helps you or at least gives you some good resources to refer to for FBA. If you have any questions, comments, or other feedback feel free to leave it below.
-Frog Out