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, для хранения пользовательской информации, такой как имя пользователя, пароль (хешированный), электронная почта, телефон, и легко расширяется для хранения FirstName, LastName или чего-то еще. Таким образом, действительно нет причин для шифрования пользовательской информации в cookie и передачи ее от клиента к серверу. Он поддерживает такие понятия, как утверждения пользователей, токены пользователей, роли пользователей и внешние логины. Вот сущности в ASP.NET Identity:
- 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 Identity. ASP.NET Identity сопоставляет вашего пользователя с объектом ClaimsIdentity на сервере - нет необходимости в настраиваемом классе IPrincipal.
При использовании облачного решения или отдельного сервера токенов, как бы вы интегрировали это с вашим текущим приложением, нужна ли мне таблица пользователей в моем приложении, как бы вы связали их?
См. Эти руководства по интеграции отдельных решений идентификации с приложением:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
https://auth0.com/docs/quickstart/webapp/aspnet-core
Как минимум, вам потребуется таблица из двух столбцов, сопоставляющая имя пользователя с идентификатором пользователя внешнего поставщика. Это то, что делает таблица AspNetUserLogins в ASP.NET Identity. Однако строки в этой таблице зависят от того, является ли запись пользователя в AspNetUsers.
ASP.NET Identity поддерживает внешних поставщиков, таких как Google, Microsoft, Facebook, любой поставщик OpenID-Connect, Azure AD уже есть. (Google и Microsoft уже внедрили протокол OpenID-Connect, поэтому вам также не нужны их пользовательские пакеты интеграции, такие как , например, этот). Кроме того, ADFS еще не доступен в ASP.NET Core Identity.
См. Этот документ, чтобы начать работу с внешними поставщиками в ASP.NET Identity:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/
Поскольку существует так много различных решений, как я могу создать корпоративное приложение, позволяющее входить в систему через Gmail / Facebook, при этом имея возможность расширяться до других систем единого входа
Как объяснялось выше, ASP.NET Identity уже делает это. Довольно легко создать таблицу «Внешние поставщики», и данные будут управлять вашим внешним процессом входа в систему. Поэтому, когда появится новый «SSO», просто добавьте новую строку со свойствами, такими как URL-адрес поставщика, идентификатор клиента и секрет, которые они вам предоставят. В ASP.NET Identity уже есть встроенный пользовательский интерфейс в шаблонах Visual Studio, но см. « Вход в социальную сеть» для более крутых кнопок.
Резюме
Если вам просто нужна таблица пользователей с возможностью входа в систему с помощью пароля и профиль пользователя, тогда ASP.NET Identity идеально подходит. Нет необходимости привлекать внешние органы. Но если есть много приложений, которым требуется доступ ко многим 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.