0

When deploying two applications (one .net 4.6 the other .net core 2.2) that share an authentication cookie to a web farm environment, the "receiving" app does not authenticate. We have a very large web forms application that we are trying to eventually migrate to .net core, so for now we are handling the authentication in the web forms app and trying to share that authentication with the .net core app. We have upgraded the authentication in the web forms app to OWIN/Katana cookie based authentication. The apps are deployed on the same servers under the same site (server.com/app1 server.com/app2). Everything works fine locally, you sign in on one and move to the other and you are still logged in. When we deploy to our servers, which are load balanced, the .net core app receives the cookie, but isAuthenticated is false.

I have been able to manually decrypt the cookie in the .net core app and it is able to print out the claims contained within it, but the IsAuthenticated flag is still false. I've tried changing the cookie domain, cookie path, security policy, and authentication type with no success.

Web Forms app Startup.cs:

var provider = DataProtectionProvider.Create(new DirectoryInfo(System.Configuration.ConfigurationManager.AppSettings["KeyRingLocation"]),
                                            (builder) => {
                                                builder.SetApplicationName("sharedApp");
                                                builder.PersistKeysToFileSystem(new DirectoryInfo(System.Configuration.ConfigurationManager.AppSettings["KeyRingLocation"]));
                                            });
            IDataProtector protector = provider.CreateProtector(
                                            "Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationMiddleware",
                                            "Identity.Application",
                                            "v2");
            app.UseCookieAuthentication(new Microsoft.Owin.Security.Cookies.CookieAuthenticationOptions
            {
                CookieName = ".AspNet.SharedCookie",
                LoginPath = new PathString("/Login.aspx"),
                CookiePath = "/",
                AuthenticationType = "Identity.Application",
                CookieSecure = Microsoft.Owin.Security.Cookies.CookieSecureOption.Always,
                CookieDomain = System.Configuration.ConfigurationManager.AppSettings["CookieDomain"],
                TicketDataFormat = new AspNetTicketDataFormat(new DataProtectorShim(protector)),
                CookieManager = new ChunkingCookieManager()
            });

.net core app Startup.cs:

services.AddDataProtection()
                .SetApplicationName("sharedApp")
                .PersistKeysToFileSystem(new DirectoryInfo(Configuration.GetSection("KeyRingLocation").Value));

            services.AddAuthentication("Identity.Application")
                .AddCookie("Identity.Application", options =>
                {

                    options.Cookie.Name = ".AspNet.SharedCookie";
                    options.Cookie.Domain = Configuration.GetSection("CookieDomain").Value;
                    options.Cookie.Path = "/";
                    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
                });

web forms login code:

            ...
            var auth = Context.GetOwinContext().Authentication;
            var identity = new ClaimsIdentity("Identity.Application");
            identity.AddClaim(new Claim(ClaimTypes.Name, profile.UserName));
            ...
            auth.SignIn(identity);

There are no errors being thrown so it is really hard to figure out what the issue is. I would expect it to respect the authentication cookie as it does running locally, but the user identity is null and isAuthenticated is false.

philthyfool
  • 194
  • 2
  • 5
  • 17
  • Use a sniffer and compare first request of working and non working app. The sniffer can be on any machine in the same subnet as client or server to capture the request/response. The default headers are probably different on the working and non working machines and can't tell by just looking at code. For example the TLS versions may be different and is failing the authentication but that would give a status error. So you should also check the response status and verify that you are getting a status of 200 OK. I'm suspicious why you are not getting an exception. – jdweng Sep 10 '19 at 15:46
  • Are you following [this](https://learn.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2) and respecting their recommendations for production environments? – Wiktor Zychla Sep 10 '19 at 16:53
  • @jdweng It is returning a 200. I will look into using a sniffer once I've tried everything else I can think of. – philthyfool Sep 11 '19 at 16:18
  • @WiktorZychla Yes I am following the linked article. When you say "and respecting their recommendations for production environments", are you referring to something in particular? This has been in production for many years and Microsoft themselves have been involved, but I haven't seen any recommendations environment-wise about this particular scenario of hosting .net 4 and core sharing cookie auth in a web farm. – philthyfool Sep 11 '19 at 16:28
  • Strange. You are getting a 200 which means everything is good. You should not be getting an authentication error unless you are attempting another connection. – jdweng Sep 11 '19 at 16:32
  • @philthyfool: by "respecting their recommendation" I mean following the recommendation starting with *For production deployments,* in the linked article. – Wiktor Zychla Sep 11 '19 at 16:53
  • @WiktorZychla Oh, I guess I thought you were talking about infrastructure. The recommendation you're referring to is encrypting the keys at rest and currently no we are not encrypting the keys at rest. I thought we would be able to get it working without encrypting the keys first. This isn't going into our production environment yet, just our QA environment which mimics production so I didn't feel the need to encrypt at rest yet. – philthyfool Sep 12 '19 at 16:24

0 Answers0