Develop Reference

Redirect loop trying to share cookie between MVC and Web Forms site

TL/DR: I am experiencing an HTTP-302 redirect loop when trying to share an authentication cookie between an ASP.NET WebForms site and an ASP.NET MVC web site that are served on separate sub-domains.
Details
a.website.com - The existing WebForms site. Works fine.
b.website.com - The new MVC site I'm trying to integrate using the shared cookie.
User reaches b.website.com and is not yet authenticated. They are redirected to a.website.com/Login.aspx.
User enters their username/password.
The user is redirected to the original desired page on b.website.com.
b.website.com receives the authentication cookie in the request, but for some reason fails to see the user as authenticated. It sends them back to a.website.com/Login.aspx.
a.website.com sees the cookie and realizes the user is authenticated, and redirects the user back to b.website.com.
Steps 4 and 5 repeat until the browser breaks the loop.
Setup
The setup follows the MSDN documentation for Configuring Forms Authentication Across Applications precisely: the two sites share machine key settings and Forms authentication settings. Both sites reside on the same server and IIS instance. Both sites force SSL. In the web.config file, the Membership and RoleManager settings are identical.
For a.website.com, which hosts the login page:
<httpCookies httpOnlyCookies="true" requireSSL="true" />
<authentication mode="Forms">
<forms name="COOKIE_NAME"
domain=".website.com"
loginUrl="login.aspx"
defaultUrl="login.aspx"
requireSSL="true"
cookieless="UseCookies"
protection="All"
enableCrossAppRedirects="true"
path="/"/>
</authentication>
<machineKey
validationKey="((validation key))"
decryptionKey="((decryption key))"
validation="SHA1"
decryption="AES" />
b.website.com is of course pretty similar, except the login URL for unauthorized users directs them to the login on site "a".
<httpCookies httpOnlyCookies="true" requireSSL="true" />
<authentication mode="Forms">
<forms name="COOKIE_NAME"
domain=".website.com"
loginUrl="https://a.website.com/login.aspx"
defaultUrl="login.aspx"
requireSSL="true"
cookieless="UseCookies"
protection="All"
enableCrossAppRedirects="true"
path="/"/>
</authentication>
<machineKey validationKey="((validation key))"
decryptionKey="((decryption key))"
validation="SHA1"
decryption="AES" />
Troubleshooting
This setup works as expected on my development machine and our test server (albeit with no domain setting and loginUrl set accordingly) where both web sites are running from the same domain, just different port numbers. For example, in local development, site "a" might run from https://development:44301/ and site "b" might run from https://development:44302/. However, on the production machine--where they are actually on different subdomains--I experience the redirect loop.
Using the browser web developer tools, I can see that the authorization cookie is being sent to b.website.com after the login redirect. Also on b.website.com, if I remove the [Authorize] attribute decorating the controller, the pages load as expected. I'm reasonably sure the issue is limited to how the MVC site is handling the authentication cookie in the limited subdomain scenario.
It sounds like the same issue was reported on SO here and here, but those users had not set enableCrossAppRedirects="true". That setting (which is enabled in my code) seems to be required for subdomain redirects, as I've already tried. This SO article details the setting a bit more and indicates the redirect should be done via SSL, which I am also doing.
What am I missing? How can I better debug the authentication failure that apparently occurs when site "b" receives but does not acknowledge the cookie?

I finally found an answer, unmentioned in the MSDN documentation I referenced above. Many thanks to Steve Smith's 2-year old blog entry.
The older WebForms site targeted a previous release of .NET, so there is an additional compatibility mode string setting on the machineKey config to handle this. If both applications were the same version, this would be unnecessary.
To be absolutely clear for future searchers-- In the web.config of the older a.website.com WebForms site, targeting an earlier .NET release, I had used an ordinary machinekey setting:
<machineKey
validationKey="((validation key))"
decryptionKey="((decryption key))"
validation="SHA1"
decryption="AES" />
In the web.config of the newer MVC site, I had to also specify the compatibility mode to work with the older site's framework:
<machineKey
compatibilityMode="Framework20SP2"
validationKey="((validation key))"
decryptionKey="((decryption key))"
validation="SHA1"
decryption="AES" />
Note that the compatibility mode string is NOT necessarily the targeted framework of the other app. Any targeted version between 2.0SP2 and 4.5 will need a setting of "Framework20SP2". Check the link above to make sure you're picking the right one!
With this in place (along with the matching forms settings in the original MSDN article), everything worked perfectly.
I foresee myself spending another day figuring out why my authentication is broken when we get around to upgrading the older site's targeted framework!

Website asks for "Authentication Required" on an MVC controller, but not others

I have an asp.net C# MVC website. It uses SimpleAuthentication and forms authentication. Everything works fine, requiring people to log in to go to pages. However, I have one controller called "ReportsController". Whenever you go to the URL's of the actions within this controller it always pops up with "Authentication Required" in the browser window.
It is only doing it for this controller and not any others. The URL will be "www.domain.com/reports". This URL works fine when I run from IIS and from my development server, but not on my live server. This is running IIS7.
I have checked my web.config and it is definately set to Forms authentication and not Windows.
Anyone have any ideas why any urls beginning with "/Reports" would not work. I am guessing it is something specific to the server, such as an IIS setting or web.config change, but I cannot figure out what this would be.
namespace ProjectName.Controllers
{
public class ReportsController : Controller
{
public ActionResult Index()
{
throw new SystemException("here");
return View();
}
}
}
Web.config:
<authentication mode="Forms">
<forms loginUrl="~/" timeout="2880" />
</authentication>

So it turns out that Sql Server Reporting Services was running on the server. This was taking control of the "/Reports" URL on all websites on that server.
I am not using SQL Server Reports, so I went to "Reporting Services Configuration Manager" on the server and removed the IP address and port it was listening on. You can also change the URL it uses instead if you still need to use this.

Azure Cloud Service Losing Session if URL doesn't contain WWW

My Azure cloud service app has users logged in with session data. If they click on a link internally that doesn't have a preceding www, then the session data is not applied. If they go back and click on a link that does have a preceding www, the session data works as expected. Does anyone know how to resolve this?
TIA

Sounds like your session cookies are not tuned to the wildcard of the domain. Can this be a problem? Check the forms section of your web.config if it contains domain attribute and if it doesn't, set it.
<authentication mode="Forms">
<forms loginUrl="/Account/LogOn" timeout="43200" domain="yourdomain.com"/>
</authentication>

ASP.NET Authentication cookie

On an application that has form based authentication, I have a standard ASP.NET Login control with the following Authenticate event handler.
void Login_Authenticate(object sender, AuthenticateEventArgs e)
{
if (Security.AuthenticateUser(Login.UserName, Login.Password))
{
e.Authenticated = true;
RedirectFromLoginPage(Login.UserName);
}
else
{
e.Authenticated = false;
}
}
The RedirectFromLoginPage function goes like this :
private void RedirectFromLoginPage(String username)
{
String returnUrl = GetReturnUrl();
FormsAuthentication.SetAuthCookie(username, true, "/");
Response.Redirect(returnUrl, true);
}
This works fine in 99% of cases. However, I sometimes get support calls from people who can't log in. They will enter their credentials, get redirected back to the home page (which is what happens when everything works fine) but they won't be logged in.
Figuring it might be a cookie problem, I tried to reproduce the problem in my environment by setting my privacy options to "Block All Cookies" and I was able to reproduce the problem. The SetAuthCookie function is called, but on the next page load HttpContext.Current.User.Identity.IsAuthenticated returns false.
In my web.config, the authentication is set like so :
<authentication mode="Forms">
<forms loginUrl="..." timeout="180" cookieless="AutoDetect"/>
</authentication>
Reading the documentation on MSDN about AutoDetect and SetAuthCookie, I got that :
AutoDetect Specifies that cookies are
used, if the device profile supports
cookies; otherwise, cookies are not
used.For desktop browsers that are
known to support cookies, a probing
mechanism will be used to try to use
cookies, when enabled. If a device
does not support cookies, no probing
mechanism will be used.
FormsAuthentication.SetAuthCookie :
Creates an authentication ticket for
the supplied user name and adds it to
the cookies collection of the
response, using the supplied cookie
path, or using the URL if you are
using cookieless authentication.
I would of thought that in my scenario, cookieless authentication would of been used but it isn't (I don't see anything in the QueryString after the redirect anyway).
If I set a breakpoint in the RedirectFromLoginPage function and test some values I get :
bool cookieSupport = Request.Browser.Cookies; //"true"
bool redirectWithCookies = Request.Browser.SupportsRedirectWithCookie; //"true"
HttpCookieMode currentMode = FormsAuthentication.CookieMode; //"AutoDetect"
I'm not sure if the Request.Browser.Cookies is meant to be true or not here. The browser does support cookies, but they are all blocked...
Anyway, I got to remote for a few minutes on a machine where the problem was happening. The privacy settings were set to medium so it should of been able to accept cookies. It was a standard Win7 / IE8 setup. I tried adding the website to the user's trusted zone, to login via https but it didn't work. Other problem setups were similar (nothing really stands out with the machines and the users tell me they have no problems on other websites)
So what am I doing wrong here?

Do you specify the domain for the forms authentication cookie in the web.config file? And does it match the domain for the website?
I believe Medium security settings in IE block third party cookies so the problem could be IE thinking your authentication cookie is a third party cookie.

A similar problem occured for me. But it was only for Internet Explorer 8. After some research, I figured that IE8 runs on cookiless mode by default. So, I changed this line in web.config:
<forms loginUrl="..." timeout="180" cookieless="AutoDetect"/> to
<forms loginUrl="..." timeout="180" cookieless="UseUri"/>, and it works fine.

ASP.NET MVC - cross sub domain authentication/membership

Hit a roadblock while implementing a sub domain based language switcher (en.domain.com loads English, jp.domain.com loads Japanese).
How do I get a single membership system to work across multiple sub domains (ASP.NET MVC C#)?
Saw something about adding domain="domain.com" to <forms > entry in web.config. Did that, but does that work when testing on local visual studio development web server?

Try creating the cookie yourself.
In AccountController you'll find this:
FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
that "creates and adds to the cookie collection". It doesn't allow modification of the domain (but does allow modification of the path, oddly). Instead create a cookie without adding to the collection, modify the necessary properties, then add to the collection:
var a = FormsAuthentication.GetAuthCookie(userName, createPersistentCookie);
//if you're debugging right here, a.Domain should be en.example.com; change it
a.Domain = "example.com";
HttpContext.Current.Response.Cookies.Add(a);
James

You have to use dot prefix, like this.
<authentication mode="Forms">
<forms domain=".tv.loc" loginUrl="~/signin" timeout="2880" name="auth" />
</authentication>

Your problem is how browsers sends cookie during request.
Cookie is generally tied to a single domain, this is for security reasons and performance. For example, user don't want to send cookie for your domain to any other domain, because your cookie may contain sensitive information.
Browser do differentiate between cookies set with en.domain.com and jp.domain.com. They do not allow cookies from one domain goes to the other because they are not on a parent domain.
The solution to your problem would be to take over the control of generating cookies. I haven't played much with ASP.NET MVC, but I'm sure it can be done not through the HTML but through a property or something. This is a very common scenario. You should set the cookies domain to "domain.com" for your production boxes, that is correct. If you're working on a local box, you should set the cookies domain to "".