.NET 5 WebAPI - czy rolami jestem w stanie obsłużyć dwa różne systemy w jednym?

Witam.
Dyskusje trwają po parę godzin od poniedziałku w sprawie nowego projektu. Wyobraźnie mamy bujną ale technologia nas chyba blokuje w zrealizowaniu pewnego problemu.

Dwa moduły jednego systemu. System jest w stanie pracować w trybie BR lub B2B.

1. Biuro Rachunkowe (BR) - zarządzanie klientami, klient (końcowy) może się zalogować i wystawić sobie dokumenty, założyć towar, dopisać kontrahenta.
2. B2B - zarządzanie klientami, klient końcowy wystawia sobie zamówienia, opiekun/admin je realizuje i zarządza cennikami klientów np. dla hurtowni

W związku z tym, że system z założenia jest albo jednym, albo drugim, to czy jest możliwość udostępniania B2B w trybie BR? Jak to ogarnąć? Czy to w ogóle możliwe za pomocą ról?

Przykład:
BIURO RACHUNKOWE - 2 klientów

1. Klient zwykły - faktury, towary/usługi, lista kontrahentów
2. Klient zwykły + B2B - faktury, towary, zamówienia, lista kontrahentów + panel B2B dla swoich klientów

HURTOWNIA (B2B) - setki klientów, którzy mogą tylko składać zamówienia za pomocą panelu. Nie ma nic wspólnego z BR ale jest tym samym oprogramowaniem i pełni funkcję tylko B2B.

Ja nie wiem czy ja to zrozumiale opisuje ale czy jestem w stanie w WebAPI jakoś ugryźć ten temat "zagnieżdżania" systemów gdzie biuro rachunkowe daje panel swojemu klientowi, a ten daje panel B2B swoim klientom, a bez biura rachunkowego system pracuje tylko w trybie panelu B2B.

Mamy wdrożony obecnie w firmie dosyć podobny panel B2B (założenia troszkę inne, ale może to Ci pomoże).

Panel B2B dla klientów, czyli standard hurtowni. I dla wybranych operatorów dostęp do backoffice i na podstawie grup i ról dostęp o którym wspominasz (u nas jest to bardziej ograniczone, bo część obsługi mamy przeniesione do ERP).

A ja chce wykorzystać ten sam system do robienia dwóch różnych rzeczy - BR lub B2B, ale klient BR może udostępniać B2B swoim klientom. Domyślnie system na start może mieć dwa tryby ale jeden z tych trybów miałby być dostępny w innym trybie. To aż brzmi głupio i śmiesznie jak się to piszę, bo to taka trochę incepcja jest. Nie chciałbym tego rozdzielać na dwa, chciałbym zrobić jedno API i jedno SPA do tego API, które taką incepcję ogarnie.

PS.
O systemie ERP nawet nie wspominam, bo chyba już każdy tutaj wie jaki :D

Wiem co masz na myśli.
Taki panel B2B w panelu B2B :) Robiliśmy do tego kiedyś przymiarki, bo szefu chciał ostro wejść na rynek + integrować ERP klienta (oczywiście każdy klient ma inny) z panelem.
No niestety musieliśmy to storpedować :)
Co do głupoty, niekoniecznie. Sporo hurtowni działa w podobny sposób. Z tą różnicą, że niektórzy udostępniają gotową nakładkę B2B. Chyba Also lub Abonline coś takiego udostępniało kiedyś. Nie interesowałem się za bardzo tym tematem, bo nie chciałem odpalać u siebie takiej hurtowni.

Ja właśnie skończylem taki system tylko nie wiem czy to dokładnie to ale działa tak:

1. Jest strona intrnetowa i kazdy moze sie tam zarejestrowac, rejestruje sie Biuro Rachunkowe i obsługuje firmy, spółki itd.
2. Takie biuro moze dodawac sobie swoich klientow czyli te spoi, firmy jDG i inne takie,
3. Moze tworzyc konta dla swoch pracownikow lub dla klientow
4. Ich klient po zalogowaniu ma do wyboru liste wszystkich biur rachunkowych do ktorych jest dopisany oraz na dole opcja ze otworz wlasne biuro. Bo oczywiscie moze uzyc swojego maila na ktorego kiedys chcialby sam tutaj miec konto jako biuro rachunkowe
5. Mozesz ograniczyc ze biuro rachunkowe nie moze tworzyc kont dla swoich klientow itd.
6. czyli system jest hurtownia dla biur racunkowych która kazde z nich ma już swoihc klientow i zarzadza dostepami do tych biur

I jestem w stanie taki system ogarnąć rolami w API?

Nie wiem co masz na mysli mowiac rolami. W moim systemie jest rola

1. Administrator - wiadomo zarzadza prawie wszystkim, wrazliwe dane do zmiany sa mozliwe tylko po ssh z kluczem z danego zakresu IP po 2FA, czyli administrator nie moze zrobic pewnych zmian ktore moglby zablokowac dzialanie systemu.
2. Moderator - to pracownik tego serwisu czyli ze ktos do niego dzowni z klientow bo costam i on moze wejsc i sprawdzic ewentualnie cos zmienic, aktywowac, przedluzyc itd. jesli sa platne rzeczy to moze wygenerowac kod np na dany pakiet na dany okres. przykladowo pakiet Plus na 3 miesiace i klientowi dac jak marudzi
3. Client - uzytkownik serwisu ktory moze miec swoje Biuro Rachunkowe lub byc kloentem istniejacego biura lub miec to i to.

Więc to sa role. Natomiast drugi parametr w pivocie u mnie okresla dostępy. czyli dany uzytkownik ma dostep do biura rachunkowego o danym ID i danym Dostępie ID wtedy wiadomo ze np dla biuyra rachinkowego ID = 312 ma dostep jako Administrator czyli widzi raporty finansowe , faktury do zaplaty itd.
ale inna osoba moze miec dostep do biura 312 jako np pracownik , ze przyjmjuje faktury od kogos ale nie widzi na jakie kworty dane biuro wystawia faktury czyli nie wie ile biuro zarabia.

Jesli zakladasz biuro to masz u mnie w systemie:
Klient o id = 199
Rola globalna: Client
Rola lokalna: Owner
Biuro ID: 312

Jesli ten sam klient nalezy do innego biura jako pracownik
Klient o id = 199
Rola Globalna Client
Rola lokalna: Employee
Biuro ID: 789

Po zalogowaniu wybierasz do czego sie logujesz jesli nalezysz do wiecej niz jedno biuro.
Wiec nie ma problemu zeby przelozyc to na API bo wysylasz zwyczajnie zwrotek z dostepem. Musisz tylko dobrze to zaplanowac na kartce

Da się takie coś ogarnąć rolami, dlaczego nie? Należy tylko zabezpieczyć endpointy w taki sposób, żeby ograniczyć użytkowników do roli jakiej się tam spodziewamy.
Jeśli chcesz wykorzystać z jakiegoś powodu te same endpointy dla użytkowników o różnych rolach które mają jednać wywoływać inne akcje pod spodem to wystarczy wtedy sprawdzić do jakiej roli przypisany jest użytkownik i go odpowiednio przekierować.

@masterc: Na zaprogramowanie takiej konfiguracji systemu będzie szło sobie w łeb strzelić. Ale dwuwarstwowe dostępy są potrzebne, tylko nie wiem czy akurat w takiej formie. Bardziej myślałem, że będzie to jedna rola na zasadzie drzewka.

TRYB BR

1. ADMIN_BR
2. KLIENT_BR -> 2a. KLIENT_B2B

TRYB B2B

1. ADMIN_B2B
2. HANDLOWIEC_B2B
3. KLIENT_B2B

@var Zatrzymałem się na momencie, w którym drzewka dostępów się "nakładają". Na podstawie tego co napisałem wyżej, jeśli damy opcję udostępniania B2B dla KLIENT_BR, to on automatycznie stałby się ADMIN_B2B, a na to sobie pozwolić nie mogę. Może ja na to patrzę ze złej strony, ale na pewno system powinien być jeden, ustawiony na odpowiedni tryb za który zapłaci klient. Co gorsze, z czasem pewnie dojdzie opcja samego fakturowania jako KLIENT_BR ale bez BR i bez B2B. Przygotowanie takiego systemu dla mnie wydaje się nierealne...

No dlatego to nakładanie u nie rozwiązałem druga zmienną czyli Biuro ID, u ciebie musiałbyś nadać dużo ról. czyli
ADMIN_BR
KLIENT_BR
ADMIN_B2B
MOD_B2B -> czyli ten twoj prawie admin br bez jakis dostepow
HANDLOWIEC_BR
KLIENT_BR

Musisz nadac odpowiednie dostepy i kazda nowa konfiguracje dostępu jaka zrobisz nazwij to wlasnie tymi ADMIN_BR B2B itd i wtedy bedziesz mial najwyzej duuuuzo kategori ról

A jak rozbić cały projekt? Dla mnie to są 4 różne projekty/aplikacje. Jestem w stanie na podstawie logowania przechodzić pomiędzy projektami? Czy API zrobić jedno, z rolami, a fronty zrobić 4? Jak się później odnieść do odpowiedniego frontu na podstawie logowania? Co jeśli KLIENT_BR będzie czyimś KLIENT_B2B? Te same logowanie, dwie różne role, w tej samej aplikacji. Czy to technologicznie w .NET 5 jest realne?

Powiem ci co zrobisz.
Zasada 1. Masz zrobic jedno API. tylko i wylacznie jedno tak jak mowisz
Zasadsa 2. Mozesz porobic nieskonczona ilosc frontow do tego api.

DLatego wlasnie musisz rozdzielic role od dostępów tak?
jezeli masz klienta_br ktory moze byc klientem_b2b i to nie tylko ejdnej firmy to nie zrobisz wszystkich kombinacji ról na zasadzie ze
klient_br -> blient_b2b = jedna rola np Start1
klient_br -> klientem_b2b i tez klientem_b2b innej firmy = Start2
wiec to moze byc zmienne. firma moze np dodac tego kloineta lub nie. dlatego tutaj za wyjatkiem sprawdzania przez api roli, zrob jeszcze zwrotke czy ma dostep do danej firmy.

Przykład:

1. Loguje sie do systemu - wysylam do api info zaloguj i podaje haslo
2. System sprawdza OK zalogowany odsylam mu token i odsylam mu liste firm do ktorych ma dostep
3. klikasz na przyklad na jedna z tych firm i system api sprawdza czy user_id = 321 ma dostep do firmy 765 jesli ma to odsylasz wynik
4. jesli nie ma bo ktos spreparowal request to odsylasz No sory misiu ale nie ,asz dostepu.

Bo nie ogarniesz rolami czegos co moze miec nieskonczenei wiele kombinacji

Dla jednej osoby taki system nie jest realny do napisania prawda?

@masterc:

Ja zawsze sprawdzam w Middleware dostepy przy kazdym requescie i tyle

Jak sprawdzasz w MW czy ktoś może zobaczyć dany obiekt?

To banalne ja akurat programuej w Laravel wiec tworze pliki Polityka dostepu (Policy) dla danego moedlu i potem zwyczajnie w middleware $user->can('access')
a tam wiem do jakiego zasobu jest żądanie bo ide na określony route prawda? wiec ten rute zeby sie dostac to user musi byc (wlascicielem lub wyzej czyli moderator lub admin) oraz jesli ma juz role wymagana to czy jest dodany do bazy dostepu jesli nie ma to odmowa. jesli jest to zwracam zasoby.

baza dostępu to mam na mysli ze jesli ja mam biuro rachunkowe o id = 2345 a ty jestes klientem moim to jesli masz dostep do swoich faktur , raportow to w tej tabeli jestes jako

office_id | user_id | access_id
---------------- | -------------------
2345 | 2 | 4

Jesli zatem jestes w tej tabeli to masz dostep, jesli cie nie ma to nie masz, chyba ze masz role wyzsza czyli moderator czy admin, wtedy nie sprawdzam tej tabeli. i to wszystko. Raz dobrze orpacujesz zasady i potem caly program staje sie banalny. A juz nie ma znaczenia czy route robie dla apliakcji calej czy tylko wystawiam to dla API fron mnie nie martwi bo on tylko odpytuje API o zasoby

Accees_id to sa flagi bitowe czyli 2,4,8,16,32,64 itd. wiec kazda wartos ma oddzielny dostep

2 | 4 | 8 | 16
---------------- | -------------------
raporty | faktury | edycja | finanse|

i teraz jak masz access = 2 to masz tylko dostep do raportow. jak masz miec raporty i finanse to masz 2 + 16 =18
jak faktury i edycja to 12 no przez operacje bitowe sprawdzam czy dana wartos wystepuje w sumie i juz mam eleganckio ogarniete dostepy lokalne

masterc napisał(a):

To banalne ja akurat programuej w Laravel wiec tworze pliki Polityka dostepu (Policy) dla danego moedlu i potem zwyczajnie w middleware $user->can('access')

a tam wiem do jakiego zasobu jest żądanie bo ide na określony route prawda? wiec ten rute zeby sie dostac to user musi byc (wlascicielem lub wyzej czyli moderator lub admin) oraz jesli ma juz role wymagana to czy jest dodany do bazy dostepu jesli nie ma to odmowa. jesli jest to zwracam zasoby.

baza dostępu to mam na mysli ze jesli ja mam biuro rachunkowe o id = 2345 a ty jestes klientem moim to jesli masz dostep do swoich faktur , raportow to w tej tabeli jestes jako

office_id | user_id | access_id
---------------- | -------------------
2345 | 2 | 4

Jesli zatem jestes w tej tabeli to masz dostep, jesli cie nie ma to nie masz, chyba ze masz role wyzsza czyli moderator czy admin, wtedy nie sprawdzam tej tabeli. i to wszystko. Raz dobrze orpacujesz zasady i potem caly program staje sie banalny. A juz nie ma znaczenia czy route robie dla apliakcji calej czy tylko wystawiam to dla API fron mnie nie martwi bo on tylko odpytuje API o zasoby

Accees_id to sa flagi bitowe czyli 2,4,8,16,32,64 itd. wiec kazda wartos ma oddzielny dostep

2 | 4 | 8 | 16
---------------- | -------------------
raporty | faktury | edycja | finanse|

i teraz jak masz access = 2 to masz tylko dostep do raportow. jak masz miec raporty i finanse to masz 2 + 16 =18
jak faktury i edycja to 12 no przez operacje bitowe sprawdzam czy dana wartos wystepuje w sumie i juz mam eleganckio ogarniete dostepy lokalne

No dobra, a jak twoja aplikacja jest czymś więcej niż nakładką na bazę danych? Weźmy takie proste wysłanie wiadomości na messengerze. Musisz sprawdzić, czy nadawca nie jest zbanowany, potem, czy ma odbiorcę na liście znajomych, jak ma, to czy nie jest przez niego zablokowany itd. To wszystko robisz w middleware?

Zresztą nawet nie trzeba iść tak daleko. Wysyłam dane do nowej faktury i ID firmy jest w ciele requestu. Wtedy parsujesz to w MW?

Każdy request który wymaga ode mnie sprawdzenia dostępu idzie przez accessMidlleware. Jak tworzysz nowa fakture to powiedzmy ze masz dostep do modulu faktury. ale w miedzy czasie ten dostep zostal cofniety. Wtedy jak wysylasz fakture to w polityce do modelu faktury masz user->can('create', Invoice) i sprawdzasz czy

1. user nie jest modem, adminem - jesli nmie jest to
2. czy jest w tej tabeli dostepow dopisany do danego biura. user_id = 324 , biuro_id = 7763, access_id = 23
   flaga Create = 8 wiec zaweira sie w 23 dlatego ma dostep i moze stworzyc fakture. Jezeli ma dostep ale nie ma flagi create no to info ze niestety nie ma uprawnien do tworzenia faktury, ale ma do wgladu na przyklad. a jesli nie ma go w tabeli w ogole to info ze niestety brak dostepu dozasobow danego biura

Kazdy rute moze meic inna polityke dostępu lub grupy route moga miec jakas polityke, zaleznie od tego jaki model jest uzywany

Co do messengera to kazdy ma miec odgorny dostep do messengera wiec tu bym nie robil middleware tylko juz po stronie kontrlera sprawdzal czy moze wyslac, czy ma usera na liscie, bo to nie ma juz nic wpsolengo z rolami i dostepami

Ja w pełni popieram to co pisze @masterc Jak się to przemyśli to nie wydaje się to wcale takie trudne do ogarnięcia. Ale trzeba to dobrze przemyśleć, bo inaczej szybko mogą pojawić się ograniczenia...