Error from authentication changes CMS 12.17.1 -> 12.26.1

November Happy Hour will be moved to Thursday December 5th.

AI OnAI Off

Home / Forums / Developers (Main Products) Forum / Content Management System 12 /

Error from authentication changes CMS 12.17.1 -> 12.26.1

Vote:

We have previously used Windows Authentication together with an IClaimsTransformation to authenticate users for the CMS and Admin parts of our website.

This was done by simply using AddNegotiate after CMS and Authentication in our startup.cs ConfigureServices method.

After updating nugets from CMS 12.17.1 to 12.26.1 we now get an error indicating "Attempting to use an incomplete authentication context." from the NegotiateHandler.

According to the aspnetcore source code on github this only happens if _negotiateState.IsCompleted is not true, which comments say shouldn't happen.

Is there any change in the CMS versions between 17 and 26 (or related nugets) that might cause this, and if so, how can the error be corrected? The only thing that changes between our auth setup working and not working is the nuget version change.

The following code used to work, but doesn't now (the IClaimsTransformation class is never reached because of the error thrown):

services.AddCmsAspNetIdentity<ApplicationUser>()
                .AddCms()
                .AddAuthentication(options =>
                {
                    options.DefaultScheme = "Windows";
                    options.DefaultAuthenticateScheme = "Windows";
                    options.DefaultChallengeScheme = "Windows";
                })
                .AddNegotiate("Windows", options => { });
            services.TryAddEnumerable(ServiceDescriptor.Singleton<IClaimsTransformation, ADGroupToRolesTransformer>());
services.AddAuthorization(options =>
            {
                options.FallbackPolicy = options.DefaultPolicy;
            });

And here's a short stacktrace of the issue.

InvalidOperationException: Attempting to use an incomplete authentication context.
Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler.HandleAuthenticateAsync()
Microsoft.AspNetCore.Authentication.AuthenticationHandler<TOptions>.AuthenticateAsync()
Microsoft.AspNetCore.Authentication.AuthenticationService.AuthenticateAsync(HttpContext context, string scheme)
Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.HandleException(HttpContext context, ExceptionDispatchInfo edi)
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

#315804

Jan 18, 2024 9:25

Vincent

Vote:

Maybe it's worth to give a try of the solution mentioned in this link by switching you middleware

https://stackoverflow.com/questions/72348006/handling-errors-and-dealing-with-an-incomplete-authentication-context

#315805

Jan 18, 2024 9:41

Vote:

Unfortunately I've tried that before and it didn't help.

#315806

Jan 18, 2024 9:53

Vincent

Vote:

Hi TW

I just test this with the specific version you mentioned (12.26.1) , everything seems working fine. When NegotiateState is in incomplete state, it seems something goes wrong in your network. I would suggest you test Windows authentication with a vanilla cms project or raise a support ticket, so you will get Opti support team to help you on this issue as well.

#315988

Jan 22, 2024 1:22

Par Holten

Vote:

Hello TW,

Did you manage to find a solution to this problem?

We are trying to upgrade to CMS 12 and struggling with this issue as well.

#318277

Feb 29, 2024 13:22

Vote:

We've pivoted to trying to get an OpenId Connect solution to work, and are making progress on that front.
The only promising lead I found for getting Windows Authentication to work is a blog post by Rick Strahl named "ASP.NET Core In Process Hosting on IIS with ASP.NET Core" which might* let IIS handle Windows Auth and just push that into the application, but I haven't had time to try it out since we've got lots to do and not much time to do it.

*this one word is doing some really heavy lifting here

Also, can't post a link directly to the blog post, hence why I just gave the author's name and the post's title

#318278

Edited, Feb 29, 2024 13:36

Magnus.Ellinge

Vote:

We had this issue as well, quite sure we had Kestrel working before because Profiling (instrumentation) in Visual Studio does not work for us with IIS Express. Either way we tried with another of our projects and it still worked with similar setup so seems to be some change in the update.

In addition to upgrading the packages recently we've added a 404 handler with UseStatusCodePageWithReExecute. Changing the order of registration seem to have solved it for us. Perhaps you're in a similiar situation.

From https://stackoverflow.com/a/74206775

app.UseAuthentication();
app.UseStatusCodePagesWithReExecute("/Home/Error", "?statusCode={0}");
app.UseExceptionHandler("/Home/Error");
app.UseAuthorization();

We have also noticed/reported a bug if you have windows + anonymous enabled when trying to access edit mode. Not sure if it's relevant here but you can check the log of kestrel for any internal redirects to /Util/Errors/Error401 (which does not exist and instead causes a 404 to be sent back to the client).

We had a temporary workaround to catch this route but it does not seem to be needed any longer after adding the UseStatusCodePages*:

/// <summary>
/// Temporary workaround for getting /episerver/cms work with anonymous/windows
/// </summary>
/// <returns>Redirect result to correct</returns>
[Route("/Util/Errors/Error401")]
public IActionResult TriggerChallengeForEditmode() => Unauthorized();

#330064

Edited, Sep 16, 2024 10:19

Vote:

We did manage to solve the issue with a small change, using HttpSys instead of Kestrel during startup. It's a bit slower to start, but has more features including kernel level authentication which is supposed to be a requirement for WIndows Authentication. Why, exactly, authentication worked with Kestrel at any point is more of a question at the moment than why it stopped working because we shouldn't have been able to use it in the way we did to begin with.
Also curious what change broke (or rather fixed?) the behaviour in Optimizely.

#330112

Sep 17, 2024 7:49

Please login to post a reply