Federated AD FS login fails silently after some time

[fraabye]

We have implemented AD FS login as described in this post: http://24days.in/umbraco-cms/2016/authenticating-with-ad-fs-and-identityextensions/

Initially, the federated login works as expected but after some time the login fails silently. The user is forwarded to the AD FS server and authenticated correctly, but is returned to the Umbraco login form.

Recycling the app / touching a config file solves the problem and users can login into to the back office again.

The tracelog does not give any obvious hints, the memory and cpu consumption is stable and nothing else seem out of the ordinary. As a consequence I am not really sure which component fails. All other systems using the AD FS server continues to work as expected.

The site is running version 7.5.6 and the login error is experienced across several browsers with cache cleared etc. @

@Shazwazza or @nul800sebastiaan can you provide any hints around extended logging configuration or similar that may help identify the root cause of the problem?

[jhauge]

Sounds a lot like the problem I had when I experienced what is described in this SO thread: http://stackoverflow.com/questions/20737578/asp-net-sessionid-owin-cookies-do-not-send-to-browser

Short story long: Does this problem go away only to return after 20 minutes or so if you restart the site? Then the problem probably lies in a timing mismatch between the cookies issued during login process.

Theres a nuget package that solves this problem called Kentor.OwinCookieSaver, which you can install, and the call app.UseKentorOwinCookieSaver(); right after app.ConfigureUserManagerForUmbracoMembers<UmbracoApplicationMember>(); in your Owin startup class.

[fraabye]

Thanks @jhauge I will give it a go. The problem does come back and roughly 20 minutes sounds right. However, I haven't had time to time it precisely yet.

[Fjellvang]

@fraabye Did this solution solve it for you?

We have the same issue, and switching to Kentor didn't actually solve the issue for us..

[fraabye]

Unfortunately, it did not. I haven't looked into it recently, but will post back if I get around to fixing it.

[appstractmeyn]

Did not solve for me either. @Shazwazza Any suggestions?

[Fjellvang]

I noticed that when our login starts failing in the 302 cookie being send is missing some info from umbraco

           {
              "name": "set-cookie",
              "value": "UMB_EXTLOGIN=***; path=/; secure; HttpOnly"
            },

is not in the cookie, (which it is on our working staging solution), similarly:

          "cookies": [
            {
              "name": "UMB_EXTLOGIN",
              "value": "*******",
              "path": "/",
              "expires": null,
              "httpOnly": true,
              "secure": true
            }
          ],

is just empty in the broken solution. Actually all UMB_EXTLOGIN and UMB_UCONTEXT is missing from the failing solution.

[appstractmeyn]

Finally solved using https://www.nuget.org/packages/AFLUmbraco

By calling the above nuget in the Notifications Notifications = new WsFederationAuthenticationNotifications { SecurityTokenValidated = async context => { var email = context.AuthenticationTicket.Identity.FindFirstValue(ClaimTypes.Email); var userService = ApplicationContext.Current.Services.UserService; var user = userService.GetByEmail(email); UmbracoADFix.LoginRedirect(email, user);

[Shazwazza]

@appstractmeyn Can you advise what this package is and what this fix is doing?

[appstractmeyn]

The package has a surface controller, that takes in two parameters, an email, and a OneTime GUID. So what it does is: it generates a GUID, maps it to the email in memory, and then calls the surface controller, which consumes this OneTime GUID and the forces the login to the backoffice. Our clients have now stopped complaining :) The Library AFLUmbraco is more than just this fix, the main purpose is to generate strongly typed models for our Umbraco document types, so that our razor views looks a lot more readable.

[umbrabot]

Hiya @fraabye,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant This bug can still be reproduced in version 8.9.0

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face: