2
votes

I have a SharePoint 2010 site that uses a trusted identity provider and a custom claims provider against my Secure Token Service. When I am in HTTP all the time it is great. When I am in HTTPS all the time it is great. But when I switch from HTTP to HTTPS, I am redirected to the STS and a loop begins between the STS and mysite/_trust.

It looks like the FedAuth cookie used from HTTP does not match the FedAuth cookie needed for HTTPS, but the STS sees you are logged in and does not issue a new cert.

Any ideas how to make the realm http:mysite.site.com and https://mysite.site.com work without issue.

UPDATE: After a lot of debugging and code changes, it seems like this is a client side issue with the cookie. If I log into HTTP and switch to HTTPS, it transfers fine. But if I go from HTTPS to HTTP, it goes into the loop. I believe this is because the cookie is set to "secure". I think that the cookie cannot be read by the HTTP site. My answer may be in finding out how to make the cookie not "secure" so it can be used on both sides.

2

2 Answers

0
votes

There are two ways to approach this issue. The issue is the FedAuth cookie is marked secure and HTTPOnly. So when you flip from HTTPS to HTTP, the cookie can't be read by SharePoint /_trust/

The approach I went with, was to modify the default.aspx in the _login directory. It can be found here C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\template\identitymodel\login\

I replaced the existing default.aspx with this default.aspx page

<%@ Assembly Name="Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharepointIdentity" Namespace="Microsoft.SharePoint.IdentityModel" Assembly="Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%> 
<%@ Import Namespace="Microsoft.SharePoint.WebControls" %> 
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 
<%@ Import Namespace="Microsoft.SharePoint" %> <%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Page Language="C#"  MasterPageFile="~/_layouts/simple.master"  %>

<asp:Content ID="PageHead" ContentPlaceHolderID="PlaceHolderAdditionalPageHead" runat="server">

</asp:Content>

<asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">

<script language="C#" runat="server">

        protected void Page_Load(object sender, EventArgs e)
        {
            string killed = "no";

            if (Request.Cookies["FedAuth"] != null)
            {
                killed = "yes";

        HttpCookie expiredCookie = new HttpCookie("FedAuth");
                expiredCookie.Expires = DateTime.UtcNow.AddDays(-1);
                Response.Cookies.Add(expiredCookie);                
            }

            string returnURL = Request["ReturnUrl"].ToString();

            Response.Redirect("/_trust/default.aspx?trust=SSO%20Trusted%20Provider&ReturnUrl=" + returnURL + "&cooke=" + killed);
        }

 </script>

</asp:Content>

There is no code behind for it.

The other way to approach it is to modify the cookie with a new cookie handler. You can see that here. http://www.msngn.com/blog/Lists/Posts/Post.aspx?ID=5

0
votes

Another answer to this is to put HTTP and HTTPS in the same zone in alternate access mapping. Then you need to override the cookiehandler to allow the same cookie to be used in HTTP as well as HTTPS.

http://www.msngn.com/blog/Lists/Posts/Post.aspx?ID=5