Приложение ASP.NET Core входит в бесконечный цикл аутентификации с помощью IdentityServer3

Предыстория
У нас есть приложение ASP.Net Core, которое находится в разработке в течение последнего года. Недавно мы преобразовали наше приложение с VS 2015 на VS 2017. Поэтому мы перешли с проекта на основе json на проект на основе csproj. Мы также обновили .NET Core runtime framework to 1.1.2.

Приложение использует централизованное IdentityServer3 для аутентификации с помощью OpenIDConnect.

После преобразования мы опубликовали приложение на нашем сервере разработки. Приложение размещено в IIS. Итак, мы установили на сервере разработки следующее:

  • Microsoft .NET Core 1.1.2 — среда выполнения (x64)
  • Microsoft .NET Core 1.0.5 и 1.1.2 — серверный хостинг Windows

На сервере разработки все прошло нормально, и мы протестировали приложение без каких-либо проблем.

Затем мы устанавливаем тот же .Net Core framework 1.1.2 и хостинг Windows Server на рабочем сервере. И скопируйте ту же опубликованную папку с сервера разработки на рабочий сервер и соответствующим образом обновите appsettings.json.

ПРОБЛЕМА
В рабочей среде, когда мы входим в систему, сервер идентификации входит в бесконечный цикл аутентификации. Fiddler показывает несколько переходов от identityServer к веб-сайту. Каждое обращение туда и обратно продолжает добавлять .AspNetCore.OpenIdConnect.Nonce и .AspNetCore.Correlation.oidc в файлы cookie, и в конечном итоге я получаю ошибку неверного запроса из-за максимального размера запроса.

Есть несколько сообщений (здесь здесь, здесь, здесь) по той же проблеме. И решение состоит в том, чтобы понизить версию Microsoft.Owin.Security.OpenIdConnect до 3.0.0
Однако мое клиентское приложение не является классическим приложением ASP.NET, а приложением ASP.NET Core, которое использует Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.2. Также обратите внимание, что оно работает на сервере разработки с тот же централизованный сервер идентификации 3 и та же версия Microsoft.AspNetCore.Authentication.OpenIdConnect 1.1.2

Итак, я предполагаю, что следующее может быть неправильным:

  1. Возможно, я забыл что-то установить на рабочий сервер (у меня наверняка установлена ​​среда выполнения .NET Core 1.1.2 и хостинг Windows Server, я не уверен, что мне нужно устанавливать что-то еще на рабочем сервере)
  2. Возможно, я неправильно настроил IIS (но что?)
  3. На рабочем сервере Как узнать, под какой версией работает приложение. (в Visual Studio в .csproj это <TargetFramework>netcoreapp1.1</TargetFramework>, но как узнать, какую версию использует опубликованный код)
  4. Единственная разница между сервером разработки и рабочим сервером заключается в том, что на сервере разработки установлена ​​классическая версия .NET Framework 4.7, а в рабочей среде — классическая версия .NET Framework 4.6.2. Однако я думаю, что это не должно вызывать проблем, потому что приложение представляет собой приложение ASP.NET Core, а не классическое приложение .NET Framework.

Я исчерпан всеми идеями, любая помощь будет очень признательна


.net-core asp.net-core openid-connect coreclr identityserver3
person LP13    schedule 23.09.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Нашел это .. В основном у нас был код для события OnTokenValidated, который получает информацию об аутентифицированном пользователе из локальной базы данных. И это было неудачно

var connectOptions = new OpenIdConnectOptions()
            {              
                AutomaticChallenge = true,
                Authority = authority,
                ClientId = clientId,
                ResponseType = IdentityConstant.ResponseType,
                AuthenticationScheme = IdentityConstant.OpenIdAuthenticationScheme,
                SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme,               
                CallbackPath = IdentityConstant.CallbackPath,
                Events = new OpenIdConnectEvents()
                {
                    OnTokenValidated = async context =>
                    {                        

                        // get email claim
                        var emailClaim = context.Ticket.Principal.Claims.SingleOrDefault(x => x.Type == IdentityClaimTypes.Email);
                        if (emailClaim == null)
                        {
                            throw new NoEmailClaimException("Could not find email claim.");
                        }

                        // this line was failing
                        var userInfo = await domainService.GetInfo(emailClaim.Value).ConfigureAwait(false);

                        // Do some stuff here                        
                    }
                }
            };

Мы исправили проблему с подключением к БД, и теперь все хорошо

person LP13    schedule 25.09.2017

arrow_upward
0
arrow_downward

Возможно, это не настоящая проблема, но я уже сталкивался с этим раньше в контексте Azure Active Directory. В моем случае я попадал в этот цикл перенаправления только тогда, когда посещал приложение без HTTPS. Я предполагаю, что это как-то связано с файлом cookie и его безопасным флагом. Я мог ошибаться.

Я принудительно использовал HTTPS в своем приложении с помощью правила перезаписи URL-адресов IIS, после чего проблема была решена.

Дополнительную информацию см. в этом комментарии к проблеме GitHub.

person tugberk    schedule 24.09.2017