TL; DR
IdentityServer = usługi szyfrowania i weryfikacji tokenów za pośrednictwem OAuth 2.0 / OpenId-Connect
ASP.NET Identity = aktualna strategia zarządzania tożsamością w ASP.NET
Jak mogę uwierzytelnić podobnie jak w poprzednich wersjach .Net, czy stary sposób nadal działa lub czy jest nowsza wersja.
Nie widzę powodu, dla którego nie można było osiągnąć starego sposobu w ASP.NET Core, ale ogólnie ta strategia została zastąpiona przez ASP.NET Identity, a ASP.NET Identity działa i dobrze działa w ASP.NET Core.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity
ASP.NET Identity wykorzystuje magazyn zapasowy, taki jak SQL Server, do przechowywania informacji o użytkowniku, takich jak nazwa użytkownika, hasło (zakodowane), adres e-mail, telefon i można go łatwo rozszerzyć o imię, nazwisko lub cokolwiek innego. Tak więc naprawdę nie ma powodu, aby szyfrować informacje o użytkowniku w pliku cookie i przekazywać je tam iz powrotem z klienta na serwer. Obsługuje pojęcia takie jak oświadczenia użytkowników, tokeny użytkowników, role użytkowników i logowania zewnętrzne. Oto jednostki w ASP.NET Identity:
- AspNetUsers
- AspNetUserRoles
- AspNetUserClaims
- AspNetUserLogins (do łączenia zewnętrznych dostawców tożsamości, takich jak Google, AAD)
- AspNetUserTokens (do przechowywania rzeczy, takich jak access_tokens i refresh_tokens zgromadzonych przez użytkownika)
Jakie są zalety i wady używania własnego serwera tokenów w porównaniu do tworzenia własnych niestandardowych zasad?
Serwer tokenów to system, który generuje prostą strukturę danych zawierającą informacje o autoryzacji i / lub uwierzytelnieniu. Autoryzacja zwykle wymaga tokenu o nazwie access_token . Byłyby to, że tak powiem, „klucze do domu”, pozwalające przejść przez drzwi do miejsca zamieszkania chronionego zasobu, zwykle interfejsu API sieci Web. W przypadku uwierzytelniania id_tokenzawiera unikalny identyfikator użytkownika / osoby. Chociaż często umieszcza się taki identyfikator w access_token, istnieje teraz dedykowany protokół do tego: OpenID-Connect .
Powodem posiadania własnej usługi tokenu zabezpieczającego (STS) byłaby ochrona zasobów informacyjnych za pośrednictwem kryptografii i kontrolowanie, którzy klienci (aplikacje) mają dostęp do tych zasobów. Ponadto standardy kontroli tożsamości istnieją teraz w specyfikacjach OpenID-Connect. IdentityServer to przykład serwera autoryzacji OAuth 2.0 w połączeniu z serwerem uwierzytelniania OpenID-Connect.
Ale nic z tego nie jest konieczne, jeśli chcesz mieć tylko tabelę użytkowników w swojej aplikacji. Nie potrzebujesz serwera tokenów - po prostu użyj ASP.NET Identity. ASP.NET Identity mapuje użytkownika na obiekt ClaimsIdentity na serwerze - nie ma potrzeby stosowania niestandardowej klasy IPrincipal.
Korzystając z rozwiązania opartego na chmurze lub oddzielnego serwera tokenów, jak zintegrowałbyś to z obecną aplikacją, czy nadal potrzebowałbym tabeli użytkowników w mojej aplikacji.
Zobacz te samouczki dotyczące integracji oddzielnych rozwiązań do obsługi tożsamości z aplikacją:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
https://auth0.com/docs/quickstart/webapp/aspnet-core
Jako minimum potrzebna byłaby tabela z dwiema kolumnami, mapująca nazwę użytkownika na identyfikator użytkownika zewnętrznego dostawcy. To właśnie robi tabela AspNetUserLogins w ASP.NET Identity. Jednak wiersze w tej tabeli zależą od tego, czy rekord użytkownika jest w AspNetUsers.
ASP.NET Identity obsługuje dostawców zewnętrznych, takich jak Google, Microsoft, Facebook, dowolny dostawca OpenID-Connect, usługa Azure AD już tam jest. (Google i Microsoft wdrożyły już protokół OpenID-Connect, więc nie potrzebujesz również ich niestandardowych pakietów integracyjnych, takich jak na przykład ten). Ponadto usługi ADFS nie są jeszcze dostępne w ASP.NET Core Identity.
Zobacz ten dokument, aby rozpocząć pracę z dostawcami zewnętrznymi w ASP.NET Identity:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/
Ponieważ istnieje tak wiele różnych rozwiązań, w jaki sposób mogę utworzyć aplikację dla przedsiębiorstw, aby umożliwić logowanie za pośrednictwem Gmaila / Facebooka, jednocześnie będąc w stanie rozszerzyć na inne SSO
Jak wyjaśniono powyżej, ASP.NET Identity już to robi. Utworzenie tabeli „Dostawcy zewnętrzni” jest dość łatwe, a dane napędzają proces logowania na zewnątrz. Kiedy więc pojawi się nowe „logowanie jednokrotne”, po prostu dodaj nowy wiersz z właściwościami, takimi jak adres URL dostawcy, identyfikator klienta i sekret, który Ci podają. ASP.NET Identity ma już wbudowany interfejs użytkownika szablonów Visual Studio, ale zobacz Logowanie społecznościowe dla fajniejszych przycisków.
Podsumowanie
Jeśli potrzebujesz tylko tabeli użytkowników z możliwościami logowania się za pomocą hasła i profilem użytkownika, ASP.NET Identity jest idealny. Nie ma potrzeby angażowania władz zewnętrznych. Ale jeśli masz wiele aplikacji wymagających dostępu do wielu interfejsów API, niezależny organ zabezpieczający i weryfikujący tożsamość oraz tokeny dostępu ma sens. IdentityServer jest dobrym rozwiązaniem lub zobacz openiddict-core lub Auth0 w przypadku rozwiązania chmurowego.
Przepraszam, że to nie trafia w sedno lub jest zbyt wstępne. Zachęcamy do interakcji, aby dotrzeć do celu, którego szukasz.
Dodatek: Uwierzytelnianie plików cookie
Aby wykonać uwierzytelnianie gołe kości za pomocą plików cookie, wykonaj następujące kroki. Ale, o ile mi wiadomo, niestandardowy podmiot oświadczeń nie jest obsługiwany. Aby osiągnąć ten sam efekt, skorzystaj z listy roszczeń ClaimPrincipalobiektu.
Utwórz nową aplikację sieci Web ASP.NET Core 1.1 w programie Visual Studio 2015/2017, wybierając opcję „Brak uwierzytelniania” w oknie dialogowym. Następnie dodaj pakiet:
Microsoft.AspNetCore.Authentication.Cookies
Zgodnie z Configurezastosowaną metodą Startup.csto (wcześniej app.UseMvc):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationScheme = "MyCookieMiddlewareInstance",
LoginPath = new PathString("/Controller/Login/"),
AutomaticAuthenticate = true,
AutomaticChallenge = true
});
Następnie utwórz interfejs użytkownika logowania i prześlij formularz html do metody akcji w następujący sposób:
[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();
}
Obiekt HttpContext.User powinien mieć niestandardowe oświadczenia i można je łatwo pobrać z kolekcji List ClaimPrincipal.
Mam nadzieję, że to wystarczy, ponieważ pełne rozwiązanie / projekt wydaje się trochę za dużo dla postu StackOverflow.