다음을 통해 공유

Unexpected authentication, and sessions issues across instances with IdentityServer3 and Orchard CMS Web Apps

  • 아티클

 

What is IdentityServer?

“IdentityServer is a framework and a hostable component that allows implementing single sign-on and access control for modern web applications and APIs using protocols like OpenID Connect and OAuth2. It supports a wide range of clients like mobile, web, SPAs and desktop applications and is extensible to allow integration in new and existing architectures.”. See, https://identityserver.github.io/Documentation/

What is Orchard CMS?

Orchard is a free, open source, community-focused Content Management System built on the ASP.NET MVC platform. See, Creating an Orchard CMS web app from the Azure Marketplace

Why would I use IdentityServer for my Orchard Web Apps?

Because of its popularity as one of the most powerful frameworks offering a single sign-on solution for user authentication. It integrates OpenID Connect and OAuth2 for all your Orchard Web Apps under one hub.

Will I have authentication or session problems using IdentityServer with my Orchard Web Apps?

Maybe in some scenarios. If you are interested, continue reading one of the known scenarios.

What kind of problems I might face, using IdentityServer with my Orchard Web Apps?

Symptoms includes, random log offs and re-login requests from the Identity Server due to instance swapping, causing session breakage.

Can you share a specific scenario using IdentityServer with an Orchard Web App?

Although I cannot share any specific details about the issue but I can mention some details. One of our customers had implemented their own single sign-on access control using the IdentityServer3 1.6.2 for all of their Orchard Web Apps. Now as a load balancing strategy the application was programmatically swapping the instances using the ARR instance cookie, with the help of Azure SDK API. This worked very well on premise, but they started discovering session breakage issues for their Web Apps hosted on Azure. Symptoms included, random authentication issues including log offs and re-login requests due to session breakage.

With the customers help, during load balancing scenario, below Steps were discovered:

1. Log into Instance A on Web App.

2. Forcibly swap instances to Instance B.

3. ​Orchard on the new instance would attempt to read the .AspNet.Federation cookie, but would be unable to decrypt the cookie, so the user is redirected the Identity Server login.

4. The Identity Server login would not be able to decrypt the IdSvr.WsFedTracking cookie (which it uses to track its session) and so it would prompt the user to log in. 

5. Upon login, the Identity server would overwrite the IdSvr.WsFedTracking and the AspNet.Federation cookies and then loads the app authenticated.

6. At this point, the session on Instance B is logged in and the cookies can no longer be read on Instance A.  So when user swaps back to instance A, they are back to Step 3.

What is the best way to ensure I do not see such issues?

Following provides some helpful information related to this:

https://github.com/IdentityServer/IdentityServer3/issues/1029

“... In IdServer, if you don't specify the data protector, it'll try to resolve the IDataProtectionProvider and retrieve a data protector. If you are using Microsoft.Owin.Host.SystemWeb for hosting in IIS, the MachineKey data protector is configured as default. If you don't, and no IDataProtectorProvider configured in Owin, IdServer will use the DpapiDataProtector. This one can be coupled to the user running the process, so you should have that in mind when protecting/unprotecting your data. If you are using the MachineKey data protector (by using Microsoft.Owin.Host.SystemWeb), you'll have a problem when one web server protects and another one unprotects, unless you specify a machine key for your app. If you do that, you'll be fine.”

In the Azure Web Apps scenario, all instances that host the same Web App will use the same machine keys by default. So the machine keys will be honored across sessions but for some reason, in customer’s case, DPAPIDataProtector was being defaulted to and being used. Now DPAPIDataProtector does not work for Web Apps when deployed in a farm scenario (i.e. multiple instances). For more information, see https://github.com/aspnet/Home/issues/466 . It turned out that because Orchard CMS uses System.Web.Hosting, which is the default ASP.NET 4.5.1 hosting service, it causes the default data protector to be DPAPIDataProtector. And hence causes session issues for Authentication.

So if you are using IdentityServer3 with your Orchard CMS Web App, ensure to use X509CertificateDataProtector, as the default DPAPIDataProtector will cause problems!

Where can I find samples for IdentityServer3?

Check https://github.com/IdentityServer/IdentityServer3.Samples . For more information, see https://github.com/IdentityServer/IdentityServer3