Что такое CookieAuthenticationOptions.AuthenticationType используется?

в моем приложении Asp.Net Identity Auth middleware setup у меня есть

app.UseCookieAuthentication(new CookieAuthenticationOptions {
    LoginPath = new PathString("/Login/"),
    //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    Provider = new CookieAuthenticationProvider {
    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
                        TimeSpan.FromMinutes(30),
                        (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie)
                    ),
    },
});

Я скопировал это из другого приложения и я просто заметил, что если я раскомментируйте AuthenticationType line, login successes (я получаю сообщение об успехе в моем регистраторе, написанном с моего контроллера), но всегда перенаправляет обратно на экран входа в систему.

на документация для CookieAuthenticationOptions он говорит:

в AuthenticationType в опциях соответствует на AuthenticationType IIdentity собственность. Для использования одного и того же типа промежуточного по аутентификации в конвейере может быть назначено другое значение.(Наследуется от AuthenticationOptions.)

Я действительно не понимаю, что это значит, почему это приведет к перенаправлению моего запроса на вход (после успешного входа не менее), и что это за опция б быть полезным для.

6
asp.net asp.net-identity authentication cookies

3 ответов

это строка, и может быть все что угодно. Но это идентификатор типа аутентификации. И у вас может быть несколько типов аутентификации: ваша БД с пользователями, Google, Facebook и т. д. Насколько я помню, это добавляется как требование к сгенерированному cookie при входе в систему.

вы должны знать поставщика проверки подлинности при выходе пользователя. Если промежуточное по аутентификации определено следующим образом:

    app.UseCookieAuthentication(new CookieAuthenticationOptions {
        LoginPath = new PathString("/Login/"),
        AuthenticationType = "My-Magical-Authentication",
        // etc...
        },
    });

затем, чтобы выйти из пользователя, вам нужна та же волшебная строка: AuthenticationManager.SignOut("My-Magical-Authentication")

также эта строка передается в ClaimsIdentity при создании principal. И без AuthenticationType Принципал не может быть аутентифицирован , потому что:

/// <summary>
/// Gets a value that indicates whether the identity has been authenticated.
/// </summary>
/// 
/// <returns>
/// true if the identity has been authenticated; otherwise, false.
/// </returns>
public virtual bool IsAuthenticated
{
  get
  {
    return !string.IsNullOrEmpty(this.m_authenticationType);
  }
}

этот метод IsAuthenticated используется через всю базу кода MVC, со всеми механизмами аутентификации, полагающимися на это.

также теоретически вы можете войти через несколько провайдеров и выйти только из одного из них за раз, оставив остальных провайдеров все еще аутентифицированными. Хотя я никогда не пробовал.

другое использование, которое я только что нашел-если вы не предоставляете CookieName в конфигурации промежуточного, тогда Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; (см. второй оператор if в конструкторе).

Я уверен, что есть больше мест, где он используется. Но самое главное-предоставить его и соответствовать названию, иначе вы получите тонкие ошибки в системе аутентификации.

4

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

У меня есть многопользовательский веб-сайт: веб-сайт работает как один экземпляр с несколькими доменами. Каждый домен является отдельным арендатором (с отдельным набором пользователей). Чтобы реализовать вход в Facebook для каждого клиента, мне нужно приложение Facebook для каждого клиента. Чтобы настроить это, мне пришлось установить уникальный CallbackPath и уникальный AuthenticationType в арендатор:

var facebookOptions = new FacebookAuthenticationOptions
{
    AuthenticationType = "Facebook-{tenantID}", 
    CallbackPath = new PathString($"/signin-facebook-{tenantID}")
}

Я думал, что он также используется как имя cookie, но это не относится к внешнему логину, такому как FacebookAuthentication. Я заметил, что это значение AuthenticationType появилось при запросе:

  1. в IdentityUserLogin.LoginProvider через authenticationManager.GetExternalLoginInfoAsync ()
  2. AuthenticationDescription.AuthenticationType через authenticationManager.GetExternalAuthenticationTypes () (кажется логично ;-))
  3. В IdentityUserLogin.LoginProvider для каждого пользователя.Логинов (аналогично 1)

и последнее, но не менее важное: значение AuthenticationType хранится в столбце базы данных AspNetUserLogins.LoginProvider.

4

Если вы настроили свежий asp.net решение, стандартный код настройки (в отличие от кода, скопированного из другого приложения) при запуске.Auth включает в себя строку AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

это создает файл cookie (с именем по умолчанию.сеть САШ.ApplicationCookie), который вы можете увидеть, если вы посмотрите в активном списке cookie Вашего браузера, который используется (среди прочего), чтобы проверить, аутентифицируется ли пользователь для каждого запроса. Если cookie нет (или пользователь находится в каким - то образом не аутентифицируется), промежуточное ПО перенаправляет на маршрут, указанный в вашей строке LoginPath = new PathString("/Login/"),

тот факт, что эта строка закомментирована в вашем коде, и ваше приложение работает, предполагает, что в вашем коде есть какая-то другая нестандартная конфигурация для аутентификации пользователя. Если раскомментировать эту строку и войти успешно, но перенаправляет обратно в login, это говорит о том, что существует некоторый конфликт между нестандартным кодом и промежуточным ПО, что приводит к промежуточному по определяя, что пользователь не прошел проверку, и получает перенаправлены обратно на LoginPath.

Я хотел бы выяснить, есть ли нестандартный код аутентификации в вашем приложении и определить, что это конкретно делает, и ответ на конфликт должен представляться. Общий совет - не изменять стандартный код аутентификации, если вы точно не знаете, каковы последствия этого (и это может усложниться, с большим количеством ловушек для неосторожный.)

в частности, на ваш вопрос, эта опция не просто полезна, она имеет основополагающее значение для стандартной работы промежуточного программного обеспечения Identity. Похоже, в вашем приложении есть нестандартный код. Если это так, вы должны полностью определить, что он делает (и это последствия) в отношении безопасности входа в систему или вернуться к стандартному идентификационному коду, если сможете.

2