Czy ktoś może wyjaśnić, co oznacza mechanizm roszczenia w nowym ASP.NET Identity Core?
Jak widzę, istnieje plik AspNetUserLogins tabela, która zawiera UserId, LoginProvideri ProviderKey.
Ale nadal nie mogę zrozumieć ani znaleźć żadnych informacji o dodaniu danych do AspNetUserClaims tabeli i w jakich sytuacjach ta tabela jest używana?
Odpowiedzi:
Co oznacza mechanizm oświadczeń w nowym ASP.NET Identity Core?
Istnieją dwa typowe podejścia do autoryzacji oparte na roli i oświadczeniu.
Bezpieczeństwo oparte na rolach
Użytkownikowi zostaje przypisana jedna lub więcej ról, za pośrednictwem których otrzymuje on prawa dostępu. Ponadto, przypisując użytkownika do roli, natychmiast uzyskuje on wszystkie prawa dostępu zdefiniowane dla tej roli.
Bezpieczeństwo oparte na oświadczeniach
Tożsamość oparta na oświadczeniach to zestaw oświadczeń. Oświadczenie to stwierdzenie, które jednostka (użytkownik lub inna aplikacja) wydaje o sobie, to tylko twierdzenie. Na przykład lista roszczeń może zawierać nazwę użytkownika, adres e-mail użytkownika, wiek użytkownika, uprawnienia użytkownika do wykonania czynności. W zabezpieczeniach opartych na rolach użytkownik przedstawia poświadczenia bezpośrednio w aplikacji. W modelu opartym na oświadczeniach użytkownik przedstawia oświadczenia, a nie poświadczenia aplikacji. Aby roszczenie miało praktyczną wartość, musi pochodzić od podmiotu, któremu ufa aplikacja.
Poniższe kroki ilustrują sekwencję tego, co dzieje się w modelu zabezpieczeń opartym na oświadczeniach:
Ale nadal nie mogę zrozumieć i znaleźć żadnych informacji, kiedy dane są dodawane do AspNetUserClaims i jakich sytuacji używa ta tabela?
Jeśli jesteś w sytuacji, w której zabezpieczenia oparte na rolach nie są używane, a zdecydujesz się użyć zabezpieczeń opartych na oświadczeniach, musisz użyć tabeli AspNetUserClaims. Aby dowiedzieć się, jak używać oświadczeń w ASP.NET Identity, zobacz poniższe łącze, aby uzyskać więcej informacji.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Aktualizacja
O której godzinie należy używać zabezpieczeń opartych na rolach, a kiedy opartych na oświadczeniach? Czy mógłbyś podać kilka przykładów?
Nie ma bardzo jasnej sytuacji, w której używałbyś lub nie używałbyś zabezpieczeń opartych na rolach lub roszczeniach, co nie przypomina przypadku, w którym używałbyś A zamiast B.
Jednak kontrola dostępu oparta na oświadczeniach umożliwia lepsze oddzielenie reguł autoryzacji od podstawowej logiki biznesowej. Zmiana reguł autoryzacji nie wpływa na podstawową logikę biznesową. Będą sytuacje, w których możesz preferować podejście oparte na roszczeniach.
Czasami roszczenia nie są potrzebne. To jest ważne zastrzeżenie. Firmy posiadające wiele aplikacji wewnętrznych mogą korzystać ze zintegrowanego uwierzytelniania systemu Windows, aby osiągnąć wiele korzyści wynikających z oświadczeń. Usługa Active Directory świetnie radzi sobie z przechowywaniem tożsamości użytkowników, a ponieważ Kerberos jest częścią systemu Windows, aplikacje nie muszą zawierać dużej ilości logiki uwierzytelniania. Tak długo, jak każda aplikacja, którą tworzysz, może korzystać ze zintegrowanego uwierzytelniania systemu Windows, być może osiągnąłeś już utopię tożsamości. Istnieje jednak wiele powodów, dla których możesz potrzebować czegoś innego niż uwierzytelnianie systemu Windows. Możesz mieć aplikacje internetowe, z których korzystają osoby, które nie mają kont w domenie Windows. Innym powodem może być to, że Twoja firma połączyła się z inną firmą, a Ty ” ponownie występują problemy z uwierzytelnianiem w dwóch lasach systemu Windows, które nie mają (i mogą nigdy) nie mieć relacji zaufania. Być może chcesz udostępniać tożsamości innej firmie, która ma aplikacje inne niż .NET Framework lub musisz udostępniać tożsamości między aplikacjami działającymi na różnych platformach (na przykład Macintosh). To tylko kilka sytuacji, w których tożsamość oparta na oświadczeniach może być dla Ciebie właściwym wyborem.
Aby uzyskać więcej informacji, odwiedź http://msdn.microsoft.com/en-us/library/ff359101.aspx
The user presents the credentials to the issuing authority that the RP application trusts.Czego możesz używać jako tego organu / wystawcy? Kilka przykładów byłoby fajnych. Przeczytałem artykuł w witrynie msdn (link, który podałeś), ale podają tylko jeden przykład: ADFS, czy są jakieś inne opcje? Nigdzie nie mogę znaleźć tych informacji. :(
Żeby dodać więcej do tego, co powiedział @Lin powyżej. Odnoszę się konkretnie do pytania:
O której godzinie należy używać zabezpieczeń opartych na rolach, a kiedy opartych na oświadczeniach? Czy mógłbyś podać kilka przykładów?
Rozważ przypadek, w którym masz system taktowania, w którym masz technika i menedżera. Pod koniec każdego tygodnia technik musi przygotować raporty zawierające informacje o taktowaniu pokazujące godziny pracy rzemieślników w tym tygodniu, które są konsolidowane i wykorzystywane przez listę płac. Takie systemy często wymagają poprawek lub poprawek przed złożeniem raportów końcowych, ponieważ nie chcesz przepłacać lub zaniżać swoich pracowników. Możesz zastosować Role-Basedpodejście dla menedżera i technika, tworząc Manager Rolei Technician Role. Ale bez tych możliwości dostępu do tych informacji. Ale oto interesująca część; Menedżer może złożyć reklamację i zezwolić technikowi na dostęp do systemów zegarowych i tworzenie raportów. Tak więc roszczenie można złożyć tylko w celu uzyskania dostępu bez edycji lub można je złożyć z możliwością dostępu i edycji.Manager Role to ten z możliwością dostępu i edytowania informacji o taktowaniu rzemieślników. Z drugiej strony możesz miećTechnician Role
To bardziej jak powiedzenie: Cóż, domyślnie jako menedżer mam dostęp do pewnych informacji, do których mój technik nie ma dostępu. Ale nie zawsze jestem w biurze? co mogę zrobić, aby mógł nadal wykonywać swoją pracę, nawet gdy mnie nie ma w pobliżu? Aby rozwiązać ten problem, system może mieć funkcję umożliwiającą menedżerom tworzenie roszczeń dla osób bez dostępu do określonych informacji. Często widzimy je wszędzie w naszych systemach ERP. Użytkownik bez dostępu do niektórych modułów, awansujący daje uprawnienia do większej liczby modułów systemu ERP, czasami zachowując tę samą rolę użytkownika.
To jest przykład, który możesz rozważyć, aby lepiej zrozumieć roszczenia i role.
Istnieją dwa typy uwierzytelniania w tożsamości ASP.Net.
Możesz użyć jednego z nich lub obu jednocześnie. Używaj opartego na rolach, gdy masz bardzo zdefiniowane rzeczy. Na przykład tworzysz dwie role: nauczyciel i uczeń. Tylko nauczyciel może dodawać przedmioty. Dlatego przypisałeś rolę nauczyciela tym użytkownikom, których chcesz mieć dostęp do dodawania przedmiotów.
Oparta na roszczeniach jest bardziej elastyczna. Załóżmy, że masz wymaganie, aby niektórzy uczniowie mogli również dodawać przedmioty. W takim przypadku musisz utworzyć jeszcze jedną rolę, która może być studentem i mieć dostęp do dodawania przedmiotu. Ale jeśli korzystasz z roszczeń opartych na roszczeniach, byłoby to bardzo łatwe. Po prostu utwórz żądanie, takie jak addSubject i przypisz je do dowolnego użytkownika, do którego chcesz uzyskać dostęp, aby dodać aubject.