Takie pytanie mam. Czy mogę jakoś powiązać np. określoną rolę z użytkownikiem zarejestrowanym przez google oauth?
No bo wiadomo. Coś takiego:
[Authorize(Roles = ...)]
//...
Ale jeśli ktoś się zarejestruje przez google? Czy jemu też mogę jakoś przypisać jakąś rolę?
Edit: ech durny jestem, przecież każdy user (ten przez google także) ma id (pierwsza kolumna), i mogę przecież do tego id przypisać rolę. No tak czy siak temat wydaje mi się ciekawy.
Wydaje mi się, że logowanie/rejestracja za pomocą Google, Facebook, czy Github stawiają użytkownika na tym samym poziomie dostępowym. Rejestrując się przez jeden z tych serwisów nie narzucasz na usera roli, wpada do "jednego worka", dopiero później jako administrator narzucasz mu role. Chcesz powiedzieć, że będziesz wisiał nad systemem i czekał, aż ktoś konto założy żeby mu szybko rolę przypisać? 
A nie potrzebujesz pomedytować, czym się różni autentykacja od autoryzacji?
Z gramem teorii praktyka będzie jaśniejsza.
Istnienie konta, sprawdzenie czy ten który się podaje, rzeczywiscie nim jest to autentykacja, i tu miejsce serwisów zewnetzrnych.
Ale "co komu do jego" (jak mawiała moja babcia) to autoryzacja.
@AdamWox: Nie no, zgoda. Jednak przez chwilę wydawało mi się, że jak jest ta właściwość "ExternalLogin" w OnPost, to zaraz po niej można dać polecenie, które nadaje domyślnie rolę np. "user". Tylko właśnie nie jestem tego pewny czy to tak działa. Tzn. jak się kogoś rejestruje zwyczajnie, to wtedy może w rejestratorze dać takie polecenie domyślnego przypisania roli "user" , ale czy to zadziała też dla osoby rejestrującej się przez google to właśnie nie jestem pewny.
Obawiam się, że przez Google nie rejestruje konta w twoim systemie. Mogę się mylić, bo nigdy tego nie potrzebowałem, ale to jest tylko po to, aby się zalogować. Zwyczajnie weryfikacja usera wykonuje się na serwerach Google, a nie u ciebie. Jeśli źle mówię, to proszę mnie poprawić ;-)
A nie potrzebujesz pomedytować, czym się różni autentykacja od autoryzacji?
Z gramem teorii praktyka będzie jaśniejsza.
Słusznie i faktycznie, przyznaję że dość często mi się myli jedno z drugim.
Istnienie konta, sprawdzenie czy ten który się podaje, rzeczywiscie nim jest to autentykacja, i tu miejsce serwisów zewnetzrnych.
Ale "co komu do jego" (jak mawiała moja babcia) to autoryzacja.
No mam nadzieję, że wreszcie kiedyś ... to zapamiętam.
AdamWox napisał(a):
Obawiam się, że przez Google nie rejestruje konta w twoim systemie. Mogę się mylić, bo nigdy tego nie potrzebowałem, ale to jest tylko po to, aby się zalogować. Zwyczajnie weryfikacja usera wykonuje się na serwerach Google, a nie u ciebie. Jeśli źle mówię, to proszę mnie poprawić ;-)
No tak, ale jak w takim razie (oraz czy to możliwe) zweryfikować "poziom możliwości" użytkownika zalogowanego przez google.
No bo niby microsoft wymyślił to rolowanie, ale po co mi ono, skoro 99% ludzi w sieci klika "google" i ma w d...pie.
A ja np. nie chcę by taki ktoś wszedł nagle mi w panel przeznaczony włącznie dla roli admin.
Systemy do "otwartego" logowania rzadko mają role w takim pojęciu w jakim ty próbujesz uzyskać. Masz dwa wyjścia, albo pakujesz każdego jako user i dajesz logowanie z Google, albo implementujesz role i ogarniasz wewnętrzną rejestracje/logowanie bez Google.
Do czego jest ten twój projekt? Może prościej będzie ciebie nakierować czy możesz dać Google, czy nie.
@AdamWox: Znaczy sorry wielkie, ale projekt i jego funkcja ... niestety nie mogę tego podać. Natomiast po przeczytaniu twoich odpowiedzi oraz po przemyśleniu sprawy ... może po prostu zrobię takie googlowe logowanie, a potem sam sprawdzę czy po zalogowaniu przez google mam dostęp
do panelu przeznaczonego dla roli admin lub user. I po jabłkach. Proste. Wtedy będę wiedział na 100. Nie?
finito napisał(a):
No tak, ale jak w takim razie (oraz czy to możliwe) zweryfikować "poziom możliwości" użytkownika zalogowanego przez google.
No bo niby microsoft wymyślił to rolowanie, ale po co mi ono, skoro 99% ludzi w sieci klika "google" i ma w d...pie.
A ja np. nie chcę by taki ktoś wszedł nagle mi w panel przeznaczony włącznie dla roli admin.
Nawet jak logujesz użytkowników zewnętrznymi providerami to nie znaczy, że nie możesz trzymać w bazie reprezentacji konta użytkownika, a raczej prawie zawsze będziesz to trzymał. Musisz przecież znać jakiś identyfikator użytkownika, bo jak inaczej powiążesz go z obiektami w swoim systemie?
Moim zdaniem to jest troszkę niebezpieczne, aby przypadkowy user mógł zalogować się Googlem i mieć możliwość zobaczenia panel admina
some_ONE napisał(a):
finito napisał(a):
No tak, ale jak w takim razie (oraz czy to możliwe) zweryfikować "poziom możliwości" użytkownika zalogowanego przez google.
No bo niby microsoft wymyślił to rolowanie, ale po co mi ono, skoro 99% ludzi w sieci klika "google" i ma w d...pie.
A ja np. nie chcę by taki ktoś wszedł nagle mi w panel przeznaczony włącznie dla roli admin.Nawet jak logujesz użytkowników zewnętrznymi providerami to nie znaczy, że nie możesz trzymać w bazie reprezentacji konta użytkownika, a raczej prawie zawsze będziesz to trzymał. Musisz przecież znać jakiś identyfikator użytkownika, bo jak inaczej powiążesz go z obiektami w swoim systemie?
No więc właśnie sam to sobie 20 minut temu uprzytomniłem.
Zależy czy chcesz zrobić całość po swojej stronie, czy wolisz oddać zarządzanie użytkownikami do Firebase. W pierwszym przypadku Google odpowiada jedynie za uwierzytelnianie a ty musisz obsłużyć autoryzację, w drugim całość może być po stronie Google. Dodatkowy plus, to łatwość integracji kolejnych dostawców tożsamości (FB itp.)
Oprócz Google Firebase możesz też rzucić okiem na Auth0, z innych nie korzystałem, autoryzację robiłem zawsze po swojej stronie, więc doczytaj w dokumentacji, czy nie plotę głupot o rolach.
Tak jeszcze na chwilę pociągnę temat. Ja po prostu się zastanawiam jak ogarnąć temat na zasadzie "komu wolno a komu nie wolno" mieć do czegoś dostęp. Jak zrobię normalną rejestrację z domyślnym przypisaniem roli zwykłego usera, a za seeduję wbudowanego admina, to wtedy wiadomo, że każdy kto się rejestruje i loguje będzie miał dostęp tylko do [Authorize(Roles = "User")] i po sprawie. Jednak jeśli owy zwykły "jeszcze nie zarejestrowany" user "się zarejestruje" przez google, to czy on "ma" dostęp do kodu, nad którym jest [Authorize(Roles = "User")] ??
Bo na chłopski rozum jak ktoś się loguje przez google, to do panelu admina się pewnie nie dostanie. Jednak co w takim razie z panelami dla roli User??
To mnie właśnie zastanawia. Ech, muszę chyba poczytać mocniej odpowiednie strony dokumentacji odnośnie OAuth, bo inaczej nic z tego nie będzie.
Bo mam nieodparte wrażenie, że po prostu czegoś tu nie rozumiem.
@finito: Przecież wystarczy uznać, ze każdy użytkownik, który się uwierzytelnił za pomocą Google to "zwykły użytkownik". Jeżeli nie ma jeszcze konta w serwisie, to każesz mu uzupełnić czego tam potrzebujesz i wszystko. Kodem ci nie odpowiem, .NET nie moja bajka, ale musi tam być coś w rodzaju "identified", czy inne "signed"..
I jeszcze raz,
Całe IAM (Identity and Access Management) składa się z 3 podstawowych elementów:
[X, Y, Z] musisz przechowywać.I jadąc po kolei:
Konkretne flow AIM są bardziej złożone, ale ogólnie:
Dzięki temu jak skonstruowane są tokeny, nie ma potrzeby, żeby usługi cokolwiek o sobie wiedziały, a jedynie potrafiły potwierdzić integralność dostarczonych tokenów.
Odpowiadając już konkretnie na:
Jednak jeśli owy zwykły "jeszcze nie zarejestrowany" user "się zarejestruje" przez google, to czy on "ma" dostęp do kodu, nad którym jest [Authorize(Roles = "User")] ??
Odpowiedź brzmi: zależy jak to zaimplementujesz. Google samo w sobie nie przechowuje żadnej roli w twojej aplikacji.