TL; DR
IdentityServer = послуги шифрування та перевірки маркерів через OAuth 2.0 / OpenId-Connect
ASP.NET Identity = поточна стратегія управління ідентифікацією в ASP.NET
Як я можу пройти автентифікацію, подібно до того, як це було зроблено в попередніх версіях .Net, чи все ще працює старий спосіб, чи є нова версія?
Я не бачу жодної причини, чому ви не змогли досягти колишнього шляху в ASP.NET Core, але загалом ця стратегія була замінена на ASP.NET Identity, і ASP.NET Identity живий і здоровий в ASP.NET Core.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity
ASP.NET Identity використовує резервне сховище, таке як SQL Server, для зберігання інформації про користувача, як-от ім'я користувача, пароль (хешований), електронну пошту, телефон, і легко розширюється для зберігання Імені, Прізвища чи будь-якого іншого. Отже, насправді немає причин шифрувати інформацію про користувача у файлі cookie та передавати її туди-сюди від клієнта до сервера. Він підтримує такі поняття, як заявки користувачів, маркери користувачів, ролі користувачів та зовнішні логіни. Ось сутності в ідентичності ASP.NET:
- AspNetUsers
- AspNetUserRoles
- AspNetUserClaims
- AspNetUserLogins (для зв’язування зовнішніх постачальників ідентифікаційних послуг, таких як Google, AAD)
- AspNetUserTokens (для зберігання таких речей, як access_tokens та refresh_tokens, накопичені користувачем)
Які плюси та мінуси використання власних віршів із сервером лексем, створюючи власний власний принцип?
Сервер маркерів буде системою, яка генерує просту структуру даних, що містить інформацію про авторизацію та / або аутентифікацію. Авторизація, як правило, приймає для маркера з іменем access_token . Так би мовити, це "ключі від будинку", що пропускають вас через дверний проріз і перебувають у резиденції захищеного ресурсу, як правило, веб-API. Для автентифікації id_tokenмістить унікальний ідентифікатор користувача / особи. Хоча такий ідентифікатор прийнято вносити в access_token, зараз для цього існує спеціальний протокол: OpenID-Connect .
Причиною власної служби безпеки токенів (STS) є захист ваших інформаційних активів за допомогою криптографії та контроль того, які клієнти (програми) можуть отримати доступ до цих ресурсів. Крім того, стандарти специфіки контролю ідентичності тепер існують у специфікаціях OpenID-Connect. IdentityServer - це приклад сервера авторизації OAuth 2.0 у поєднанні з сервером автентифікації OpenID-Connect.
Але нічого з цього не потрібно, якщо вам просто потрібна таблиця користувачів у вашому додатку. Вам не потрібен маркерний сервер - просто використовуйте ідентифікатор ASP.NET. ASP.NET Identity відображає вашого користувача до ClaimsIdentity об'єкта на сервері - немає потреби у власному класі IPrincipal.
Використовуючи хмарне рішення або окремий сервер Token, як би ви інтегрували це з вашим поточним додатком, чи все одно мені знадобиться таблиця користувачів у моєму додатку, як би ви пов’язали ці два?
Перегляньте ці посібники з інтеграції окремих рішень для ідентифікації з додатком:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
https://auth0.com/docs/quickstart/webapp/aspnet-core
Як мінімум вам знадобиться таблиця у два стовпці, що відображає ім’я користувача до ідентифікатора користувача зовнішнього постачальника. Це те, що робить таблиця AspNetUserLogins в ідентифікації ASP.NET. Рядки в цій таблиці, однак, залежать від того, що є записом користувача в AspNetUsers.
ASP.NET Identity підтримує зовнішніх постачальників, таких як Google, Microsoft, Facebook, будь-який постачальник OpenID-Connect, Azure AD вже є. (Google і Microsoft вже впровадили протокол OpenID-Connect, тому вам також не потрібні їх власні пакети інтеграції, як , наприклад, цей ). Крім того, ADFS ще не доступний в ASP.NET Core Identity.
Перегляньте цей документ, щоб розпочати роботу із зовнішніми постачальниками в ідентифікації ASP.NET:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/
Оскільки існує так багато різних рішень, як я можу створити корпоративний додаток, щоб дозволити вхід через Gmail / Facebook, маючи при цьому можливість розширення до інших єдиних систем
Як пояснювалося вище, ASP.NET Identity це вже робить. Створити таблицю "Зовнішні постачальники" досить просто, а дані керують процесом зовнішнього входу. Тож, коли з’являється новий "SSO", просто додайте новий рядок із такими властивостями, як URL-адреса постачальника, ідентифікатор клієнта та секрет, який вони вам дають. ASP.NET Identity вже має вбудований інтерфейс, вбудований там шаблони Visual Studio, але див. Social Login для кнопок охолодження.
Резюме
Якщо вам просто потрібна таблиця користувачів із можливостями входу за паролем та профілем користувача, тоді ідентифікація ASP.NET ідеальна. Не потрібно залучати зовнішні органи. Але, якщо у вас багато додатків, які потребують доступу до багатьох API, тоді незалежний орган із захисту та перевірки ідентичності та маркерів доступу має сенс. IdentityServer добре підходить, або див. Openiddict-core або Auth0 для хмарного рішення.
Приношу свої вибачення, що це не є ціллю або якщо це занадто вступно. Будь ласка, не соромтеся взаємодіяти, щоб дійти до бичачого ока, якого ви шукаєте.
Додаток: Аутентифікація файлів cookie
Щоб виконати автентифікацію оголених кісток за допомогою файлів cookie, виконайте такі дії. Але, наскільки мені відомо, призначений для користувача претензійний принцип не підтримується. Щоб досягти того самого ефекту, скористайтеся списком претензій ClaimPrincipalоб'єкта.
Створіть нову веб-програму ASP.NET Core 1.1 у Visual Studio 2015/2017, вибравши "Без автентифікації" у діалоговому вікні. Потім додайте пакет:
Microsoft.AspNetCore.Authentication.Cookies
За наявним Configureметодом Startup.csце (раніше app.UseMvc):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationScheme = "MyCookieMiddlewareInstance",
LoginPath = new PathString("/Controller/Login/"),
AutomaticAuthenticate = true,
AutomaticChallenge = true
});
Потім побудуйте інтерфейс користувача для входу та опублікуйте html-форму до методу дії, наприклад:
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(String username, String password, String returnUrl = null)
{
ViewData["ReturnUrl"] = returnUrl;
if (ModelState.IsValid)
{
var claims = new List<Claim>
{
new Claim(ClaimTypes.Name, username),
new Claim("FirstName", "Alice"),
new Claim("LastName", "Smith")
};
var identity = new ClaimsIdentity(claims, "Password");
var principal = new ClaimsPrincipal(identity);
await HttpContext.Authentication.SignInAsync("MyCookieMiddlewareInstance", principal);
return RedirectToLocal(returnUrl);
}
ModelState.AddModelError(String.Empty, "Invalid login attempt.");
return View();
}
Об'єкт HttpContext.User повинен мати ваші власні вимоги та легко отримувати колекцію List з ClaimPrincipal.
Я сподіваюся, цього вистачить, оскільки повне рішення / проект здається трохи великим для публікації StackOverflow.