Które dane powinny być przechowywane jako „Roszczenie”?

W ASP.Net Core uważam, że Claimsautoryzacja jest bardzo nieokreśloną metodą. Możemy dodać wszystko jako ClaimTypei ClaimValuesparować; grupy, imię, nazwisko, brithdate, canAccessThisURI, isEditor itp. Jednak to podejście (przechowywanie wszystkiego, co można przechowywać jako oświadczenia) spowoduje utworzenie ogromnej tabeli oświadczeń, która zawiera 50% moich danych aplikacji.

Zastanawiam się, jako dobrą praktykę, jakie są wspólne dane, które powinny być przechowywane jako roszczenia?

Roszczenie to po prostu fakt dotyczący użytkownika, który może potencjalnie posłużyć do zidentyfikowania lub autoryzacji kogoś w twoim systemie. Te dwa ograniczenia powinny wystarczyć, aby ograniczyć roszczenia.

Niektóre pomysły dotyczące roszczeń obejmują:

• identyfikator użytkownika
• Nazwa Użytkownika
• adres e-mail użytkownika
• role
• członkostwo w grupach

Metadane użytkownika powinny być ograniczone do tego, co jest potrzebne do personalizacji aplikacji dla użytkownika i do powiązania użytkownika z jego danymi. Identyfikator użytkownika wystarczy, aby powiązać użytkownika z danymi lub podać ścieżkę audytu. Nie bądź chciwy.

Role i członkostwa w grupach są roszczeniami autoryzacyjnymi. Na przykład, jeśli masz grupy w aplikacji, lista grup, do których użytkownik należy, pozwala szybko sprawdzić, czy mogą uzyskać dostęp do grupy prywatnej, czy nie. Role są nieco bardziej szczegółowe i mówią o tym, jakie uprawnienia ma użytkownik. Zazwyczaj są one specyficzne dla aplikacji, więc dodaj tylko to, czego potrzebujesz, aby je egzekwować.

Istnieje wiele systemów, zwłaszcza systemów STS / federacyjnych, które robią to w ten sposób:

• jedno twierdzenie, które opisuje użytkownika wyjątkowo
• asortyment roszczeń opisujących ogólne rzeczy koncepcyjne, do których mają dostęp (i inne osoby)

Dane „profilu” użytkownika w aplikacji mogą nie zostać przetłumaczone na / ze źródła uwierzytelnienia, którego używasz, i nie możesz używać tych samych punktów końcowych przez cały czas lub wszystkich użytkowników.

Jeśli znasz stare uwierzytelnianie formularzy, jest ono analogiczne do modelu nazwy użytkownika i roli, a wiele wbudowanych elementów nadal wygląda tak, jeśli odpowiednio używasz System.Security.Claims.ClaimTypy nazwy i roli.

Ani stary, ani nowy model nie dawał wiele po wyjęciu z pudełka roszczeń lub dziedziczenia ról, ale nie jest to szczególnie trudne do wdrożenia, a jego wdrożenie pozwala ograniczyć liczbę roszczeń lub ról, które trzeba zachować w grze od żądania poprosić.

Jeśli Twoja aplikacja musi śledzić datę urodzin, ale nie musi jej używać w mechanizmie bezpieczeństwa, to naprawdę nie ma żadnych korzyści z utrzymywania jej w ramach dochodzenia roszczeń. Umieść go w osobnym zestawie danych profilu lub coś takiego.

Jeśli twoja aplikacja musi otrzymać datę urodzin jako roszczenie z innego systemu, szukasz czegoś bardziej przypominającego dostosowanie federatedAuthentication lub pozostawienie dodatkowego roszczenia.