[Khaine]

#programowanie #backend #csharp

Tym razem pytanie z grupy designu systemu od strony bebechów.

Generalnie w starych aplikacjach pisanych przez raczej średnio zorganizowanych ludzi autoryzacja jest zbudowana na systemie ról. Mamy tam 5 czy 6 twardo zdefiniowanych ról i potem w pierdylionie miejsc w kodzie mamy sprawdzenia typu if (User.Role == Roles.Admin) to cośtam xD Zahardkowane bo czemu nie, jak lepić paździerza to po całości.

A potem przychodzi klient i mówi "wiecie co, UserX to jest taki trochę przygłupi weźcie mu zablokujcie dostęp do czegośtam". W tym momencie moi poprzednicy robili pikachu face bo role na sztywno i aby srace stało się zadość uwieszali w kodzie na sztywno if (ClientId == x) xDDD

Kupa straszna i szkoda szczempić ryja tak naprawdę, więc mając możliwość położyć podwaliny pod coś nowego wolałbym chociaż spróbować się przed tym zabezpieczyć. Zdecydowałem się więc na system claimów gdzie założenie jest takie, że to użytkownik z odpowiednimi uprawnieniami będzie w stanie tworzyć własne claimy i ewendualnie nadawać użytkownikom dynamicznie, i chciałbym wiedzieć czy macie jakieś doświadczenia jak da się to rozwiązać.

Jednym z moich pomysłów było dorzucanie do każdego endpointu zestawu Permissions które tworząc claima będziemy mogli odklikiwać. Definiujemy sobie np. że dla /users/getUsers obecne możliwości wpływania na dostęp są takie a takie i np. jedno z uprawnień to "ShowHiddenUsers", którego jak ktoś miał nie będzie to nie zobaczy użytkowników np. systemowych. Mogło to być dodane przy pierwszej wersji systemu, bo programista o tym od razu pomyślał a mogło być dodane takie uprawnienie na życzenie - ale wtedy możemy je dać wszystkim klientom na raz, dodać w jednym miejscu w kodzie (a nie uwieszać ify w 54 miejscach XD) i co najwyżej dać to uprawnienie wszystkim użytkownikom aby pozostali klienci nie zauważyli nawet, że powstało nowe uprawnienie (dolepić im je po prostu do claimów). Ale może są na to jakieś lepsze metody?

[budyn]

@Khaine: Role to po prostu zdefiniowana kolekcja konkretnych claimów.
W sumie to używasz je tylko jak chcesz przypisać łatwiej te claimy.
W kodzie oczywiście sprawdzasz tylko claimy.
Nie widzę przeciwwskazań, żeby był sobie endpoint, który może modyfikować konkretne claimy już.
A żeby jeszcze bardziej elastycznym możesz mieć endpoint, który przyjmuje role albo claimy i je w zależności tego co podałeś dodaje/odejmuje użytkownikom.
Tak bym to zrobił

[Khaine]

@budyn: Tak właśnie myślałem, że role sobie mogą być ALE po pierwsze możemy definiować nowe role w locie złożone z dowolnych claimów jakie tylko mogą być. Walidujemy claimy a rola to jest tylko pakiet żeby było łatwiej to zebrać do kupy.

[bacteria]

@Khaine: ty chcesz to przebudowac i szukasz porady jak czy pytasz ogolnie o kontrole dostepu?

[Khaine]

@bacteria: Robię coś od nowa, co może w przyszłości ewoluować w następcę tego starego paździerza i chciałbym to zaprojektować tak, aby nie powtórzyć problemów starego systemu, tylko wymyślić nowe xD Chciałbym to po prostu zrobić dobrze a nie mam za bardzo porównania do innych.

[bacteria]

@Khaine: no to ogolnie u nas najlepiej sie sprawdzaja grupy w active directory. Autoryzujesz grupy a ich management oddajesz w rece it supportu ewentualnie team infrastruktury. Ten sam patent mozna wykorzystac w roznych tierach aplikacji, np. W data access layerach jak Sql, itd. Na start polecam troche literatury https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups

[PiesLat2230]

@Khaine: tzw system flag
użytkownik o danym id ma x flag, możesz to w bazie danych nawet zhardcodować
userId flagEdit flagWrite etc etc true albo false i elo