U4-6820 - Can't login to back office when logged in as a member on the front end.

Created by Ryan Mann 11 Jul 2015, 05:52:57 Updated by Neil Gaietto 07 Nov 2016, 15:07:50

We are using Windows Identity Foundation for front end authentication. When a user is logged in their Umbraco Member is created for them on the fly however we do not generate a Forms Cookie, instead it's a FedAuth cookie. The request is still authenticated and it still get's the same claims as Forms Auth. However WIF allows us to easily create SSO with Passive Redirect to our CAS Login site.

It works perfectly on the front end and we can still use the Member Service.

However when we are logged into the front end, we cannot log in as user in the back office, it just fails, no error in the log, the only error I get is in the angular layer "red pop up"

"Server call failed for checking authentication" then says to check the log and there is nothing there about it.

In an attempt to get around this, I create a custom SessionAuthenticationModule (the part of WIF that creates the authenticated session from the FedAuth Cookie). I then overrode it's OnAuthenticated event and if the local path is /umbraco I return and do nothing causing WIF to be bypassed.

In doing that I can log in the back office as a user while being logged in the front as a member... However it created a new problem...

Surface Controllers are hosted on a /umbraco url in the back office, so WIF doesn't run on the surface controller and I need to use surface controllers on some partial views etc that need to know if the member is logged in.

I'm pretty sure this is a bug, something was changed in the user/member logic betwen 6.1 and 7.1.2 because we didn't have this problem on 6.0.

Comments

Ryan Mann 11 Jul 2015, 06:18:40

I was able to bypass the problem by changing my SessionAuthenticationModule override, to

public class UmbracoSessionAuthenticationModule : SessionAuthenticationModule
{
    protected override void OnAuthenticateRequest(object sender, EventArgs eventArgs)
    {
        var path = HttpContext.Current.Request.Url.LocalPath.ToLower();
        if (path.StartsWith("/umbraco") && !path.StartsWith("/umbraco/surface"))
            return;
        base.OnAuthenticateRequest(sender, eventArgs);
    }
}

This allows WIF to run on the surface controllers, but turns it off for anything else under /umbraco. This could cause the backoffice to break though if any of the back office uses surface controllers.

I checked all the routes being generated, and the only other surface controllers besides mine in the routes are

umbraco/Surface/UmbLogin// umbraco/Surface/UmbLoginStatus// umbraco/Surface/UmbProfile// umbraco/Surface/UmbRegister//

I am pretty sure those are all for the front end macros and stuff.


Neil Gaietto 07 Nov 2016, 15:07:50

@ryios

We had this same issue and it was because we were registering our own OWIN cookie based authentication AFTER umbraco registered theirs. This is something you would not know you were doing wrong unless you really dug into the source code where it says not to do this above "ConfigureMiddleware" in UmbracoDefaultOwinStartup.cs. It would be nice if umbraco documented this on the web.

So you should be registering your authentication within the 'Configuration(IAppBuilder app)' of your own implementation of UmbracoDefaultOwinStartup. Make sure your authentication happens before you call 'base.Configuration(app)'.

If you are setting up your authentication any differently then you still need to make sure you register your authentication before umbraco registers theirs via the "ConfigureMiddleware" which gets called in UmbracoDefaultOwinStartup.Configuration


Priority: Normal

Type: Bug

State: Submitted

Assignee:

Difficulty:

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.3.0, 7.2.1

Due in version:

Sprint:

Story Points:

Cycle: