SIDE NOTE: Yet another kudos to the fabulous folks that run this site. This latest version now retains even LESS formatting from Word and Visual Studio than before! I didn't think it was possible to make this site any worse than it was, and yet you've shattered, dare I say blown away, my expectations in this regard. Congrats! I hope to follow suit soon myself and ditch Word, Excel and PowerPoint for notepad - who needs formatting anyways?
I recently needed to bypass the provider selection page that you get when you enable multiple authentication providers on a single zone in SharePoint 2010. The scenario I had was a fairly simple one, but the methodology can be extended quite a bit to support much more complicated scenarios. In my case, I had Windows authentication and forms based authentication (FBA) enabled on a zone. However I always wanted to redirect users to use FBA for this particular scenario.
Accomplishing this was relatively straightforward by following these steps:
protected override void OnLoad(EventArgs e)
//if this isn't a postback, then the user hasn't selected which
//auth provider they want to use
//in this case we want to always refer the person to forms login
//grab all the query string parameters
System.Text.StringBuilder qp = new System.Text.StringBuilder(2048);
foreach (string key in this.Request.QueryString.Keys)
qp.Append(key + "=" + this.Request.QueryString[key] + "&");
//redirect to the forms login page
this.Response.Redirect("/_forms/default.aspx?" + qp.ToString());
catch (Exception ex)
<%@ Page Language="C#" CodeBehind="Default.aspx.cs" Inherits="MultiAuthLoginPage._Default,MultiAuthLoginPage, Version=22.214.171.124, Culture=neutral, PublicKeyToken=907bf41ebba93579" MasterPageFile="~/_layouts/simple.master" %>
<%@ Assembly Name="Microsoft.SharePoint.IdentityModel, Version=126.96.36.199, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharepointIdentity" Namespace="Microsoft.SharePoint.IdentityModel" Assembly="Microsoft.SharePoint.IdentityModel, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="Microsoft.SharePoint, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Import Namespace="Microsoft.SharePoint.WebControls" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
<SharePoint:EncodedLiteral runat="server" EncodeMethod="HtmlEncode" Id="ClaimsLogonPageTitle" />
<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
<SharePoint:EncodedLiteral runat="server" EncodeMethod="HtmlEncode" Id="ClaimsLogonPageTitleInTitleArea" />
<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>
<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">
<SharePoint:EncodedLiteral runat="server" EncodeMethod="HtmlEncode" Id="ClaimsLogonPageMessage" />
<SharepointIdentity:LogonSelector ID="ClaimsLogonSelector" runat="server" />
That’s all there is to it. I tested this with a standard user login, as well as opening documents directly from the Microsoft Office 2010 clients. One other thing worth noting here: this changes the behavior for ALL web applications in your farm! Again, that’s why it’s a simple example. However you could easily look at the host name of the request (which maps to your web application) and make different authentication decisions based on which web application is being accessed or even which site collection. You can obviously also make other decisions based on information you have about the current user. The HttpRequest.Context.Current, Page.Request and Page.Response classes can provide you with a lot of information to make these kinds of decisions.
Looks great STeve, but if I want to authenticate in via AD (this is a off premise server), how can I chose to authenticate that way?
Would it not be easier to create a custom login form and handle both authentication methods in one?
@Charles, it depends on your requirements, which is why I tried to stress that this was a simple example for one scenario. In this particular case I wanted all users to go through FBA so there was no need to handle both auth types.
Hello, Steve. Thanks for great article!
Can i do that without change original default.aspx - just configure app to use custom login page?
Found an interesting blog about using the custom login page field and specifying the trust provider. Thisi s the custom login page, not code option. Only issue is that logout breaks so.....
first reading the article i wondered why not use a custom login page...
I seems to me that using the custom login page is not a good idea because the search application cannot handle the 302 Redirect. (highest level error - object moved)
now i do it the same way: replace the default.aspx in the IDENTITYMODEL\LOGIN folder.
and search crawler does fine.
btw. the search crawler solves the "IIS Sharepoint warm up" problem. crawling all site-cols in the web-app warms them up. rightly?!
I implemented the code and it works. However, it's actually throwing an exception when I attached the code to the process and debugging it. Another thing I notice is the Sign in as different user link doesn't work, The query string got appended twice.
I have a problem. I get parse error 'could not load type MultiAuthLogin' even though I have registered the library in GAC.
<%@ Page Language="C#" CodeFile="~/Default.aspx.cs" Inherits="MultiAuthLoginPage.MultiAuthLoginPage.Default" MasterPageFile="~/_layouts/simple.master" %>