Chcę stworzyć dość prosty system kontroli dostępu oparty na rolach, korzystając z systemu autoryzacji Keycloak. System zastępowany przez Keycloak pozwala nam stworzyć „użytkownika” będącego członkiem jednej lub kilku „grup”. W tym starszym systemie użytkownik otrzymuje „pozwolenie” na dostęp do każdej z około 250 „możliwości” albo poprzez członkostwo w grupie (gdzie grupom są przypisane uprawnienia), albo przez bezpośrednie przyznanie uprawnień użytkownikowi.

Chciałbym zmapować stary system do autoryzacji Keycloak.

Mapowanie każdej „zdolności” w istniejącym systemie powinno być dla mnie łatwe do zasobu Keycloak i zestawu zakresów Keycloak. Na przykład funkcja „viewAccount” w oczywisty sposób odwzorowuje zasób „konto” i zakres „widoku”; a „viewTransaction” mapuje na zasób „transakcji” ... ale czy najlepiej jest utworzyć tylko jeden zakres „widoku” i używać go w wielu zasobach (konto, transakcja itp.)? A może powinienem utworzyć zakres „viewAccount”, zakres „viewTransaction” itp.?

Podobnie jestem trochę zdezorientowany co do uprawnień. Czy w przypadku każdego praktycznego połączenia zasobów i zakresu zwykle tworzy się pozwolenie? Co robi Keycloak, jeśli istnieje wiele uprawnień pasujących do danego zasobu / zakresu? Domyślam się, że zamiarem Keycloak jest umożliwienie mi skonfigurowania macierzy uprawnień dla zasobów i zakresów, więc na przykład mógłbym mieć uprawnienia dostępu do „kont” i uprawnienia do zakresu „widoku”, więc miałbym uprawnienia przeglądać konta?

Pytam, ponieważ wydaje się, że rezultatem tego wszystkiego jest to, że moja stara funkcja „viewAccount” kończy się utworzeniem zasobu „Account” z zakresem „View” i uprawnieniem „viewAccount”, co wydaje się przenosić mnie z powrotem tam, gdzie byłem. Co jest w porządku, jeśli jest poprawne.

Wreszcie, oczywiście, potrzebuję zestawu zasad, które określają, czy należy zastosować viewAccount. Ale czy mam rację, że to oznacza, że ​​potrzebuję polityki dla każdej starszej grupy, do której mógłby należeć użytkownik? Na przykład, jeśli pełnię rolę „helpdesk”, potrzebuję zasady „członkostwa w helpdesku”, którą mogę następnie dodać do uprawnienia „viewAccount”. Czy to jest poprawne?

Dzięki,

znak

Wiem, że spóźniłem się 2+ lata, ale myślę, że podzielę się tym, co wiem i miejmy nadzieję, że złagodzę ból dla przyszłych czytelników. Pełna przejrzystość - w żadnym wypadku nie jestem ekspertem od Keycloak / OAuth / OIDC i wiem, że to głównie z czytania dokumentów, książek, starego dobrego YouTube'a i zabawy z narzędziem.

Ten post będzie składał się z dwóch części:

1. Postaram się odpowiedzieć na wszystkie Twoje pytania najlepiej jak potrafię
2. Pokażę ci wszystko, jak możesz bawić się zasadami / zakresami / uprawnieniami w Keycloak bez konieczności wdrażania oddzielnej aplikacji, aby lepiej zrozumieć niektóre z podstawowych pojęć w tym wątku. Zwróć jednak uwagę, że ma to głównie na celu rozpoczęcie pracy. Używam Keycloak 8.0.0.

Część I.

Kilka terminów, zanim zaczniemy:

• W Keycloak możesz utworzyć 2 typy uprawnień: oparte na zasobach i na zakresie .
• Mówiąc najprościej, w przypadku Resource-Baseduprawnień stosujesz je bezpośrednio do swojego zasobu
• Aby uzyskać Scoped-Basedpozwolenie, stosujesz je do zakresu (-ów) lub zakresu (-ów) i zasobu.

Czy najlepszą praktyką jest tworzenie tylko jednego zakresu „widoku” i używanie go w wielu zasobach (konto, transakcja itp.)? A może powinienem utworzyć zakres „viewAccount”, zakres „viewTransaction” itp.?

Zakresy reprezentują zestaw praw do chronionego zasobu. W twoim przypadku masz 2 zasoby: accounti transactiondlatego skłaniałbym się do drugiego podejścia.

W dłuższej perspektywie, o globalny viewzakres związaną ze wszystkimi swoimi zasobami (np account, transaction, customer, settlement...) sprawia, że trudno jest autoryzacja zarówno zarządzanie i dostosować się do zmian wymagań bezpieczeństwa.

Oto kilka przykładów, które możesz sprawdzić, aby poczuć projekt

• Slack API
• Box API
• Naszywka

Zwróć jednak uwagę - nie twierdzę, że nie należy udostępniać zakresów między zasobami. W rzeczywistości Keycloakpozwala na to dla zasobów z tym samym type. Możesz na przykład potrzebować obu viewAccounti viewTransactionzakresu, aby odczytać transakcję na danym rachunku (w końcu możesz potrzebować dostępu do rachunku, aby wyświetlić transakcje). Twoje wymagania i standardy będą miały duży wpływ na Twój projekt.

Czy w przypadku każdego praktycznego połączenia zasobów i zakresu zwykle tworzy się pozwolenie?

Przepraszam, nie do końca rozumiem pytanie, więc będę trochę szerszy. Aby przyznać / odmówić dostępu resource, musisz:

• Zdefiniuj swoje zasady
• Określ swoje uprawnienia
• Zastosuj swoje zasady do swoich uprawnień
• Skojarz swoje uprawnienia z scopelub resource(lub obydwoma)

aby egzekwowanie zasad zaczęło obowiązywać. Zobacz proces autoryzacji .

To, jak sobie z tym poradzisz, zależy wyłącznie od Ciebie. Możesz na przykład:

• Zdefiniuj indywidualne zasady i przypisz je do odpowiednich uprawnień.

• Jeszcze lepiej, zdefiniuj indywidualne zasady, a następnie zgrupuj wszystkie powiązane zasady w ramach aggregatedpolityki (polityki zasad), a następnie skojarz tę zagregowaną politykę z scope-baseduprawnieniem. Możesz mieć to scoped-baseduprawnienie dotyczące zarówno zasobu, jak i całego powiązanego z nim zakresu.

• Możesz też dalej rozdzielić swoje uprawnienia, wykorzystując dwa oddzielne typy. Możesz tworzyć uprawnienia wyłącznie dla swoich zasobów za pomocą resource-basedtypu uprawnienia i oddzielnie kojarzyć inne uprawnienia wyłącznie z zakresem za pomocą scope-basedtypu uprawnienia.

Masz opcje.

Co robi Keycloak, jeśli istnieje wiele uprawnień pasujących do danego zasobu / zakresu?

To zależy od

1. Serwer zasobów Decision Strategy
2. Każde pozwolenie Decision Strategy
3. LogicWartość każdej polisy .

LogicWartość jest podobna Java !operatora. Może to być Positivelub Negative. Gdy Logicto Positive, ostateczna ocena polityki pozostaje niezmieniona. Kiedy jej Negative, ostateczny wynik jest zanegowany (np. Jeśli w ocenie zasady jest fałsz i tak Logicjest Negative, to tak będzie true). Aby uprościć sprawę, załóżmy, że opcja Logicjest zawsze ustawiona na Positive.

To Decision Strategyjest to, czym naprawdę chcemy się zająć. Decision StrategyMoże być albo Unanimousalbo Affirmative. Z dokumentów,

Strategia decyzyjna

Ta konfiguracja zmienia sposób, w jaki aparat oceny zasad decyduje, czy zasób lub zakres powinien zostać przyznany na podstawie wyniku wszystkich ocenionych uprawnień. Twierdzący oznacza, że ​​co najmniej jedno zezwolenie musi dać pozytywną decyzję, aby przyznać dostęp do zasobu i jego zakresów. Jednogłośność oznacza, że ​​wszystkie pozwolenia muszą zostać ocenione pozytywnie, aby ostateczna decyzja była również pozytywna. Na przykład, jeśli dwa uprawnienia do tego samego zasobu lub zakresu są ze sobą w konflikcie (jedno z nich przyznaje dostęp, a drugie odmawia dostępu), uprawnienie do zasobu lub zakresu zostanie przyznane, jeśli wybrana strategia jest potwierdzona. W przeciwnym razie pojedyncza odmowa dowolnego uprawnienia spowoduje również odmowę dostępu do zasobu lub zakresu.

Skorzystajmy z przykładu, aby lepiej zrozumieć powyższe. Załóżmy, że masz zasób z 2 uprawnieniami i ktoś próbuje uzyskać do niego dostęp (pamiętaj, że Logicdotyczy Positivewszystkich zasad). Teraz:

1. Permission Onema Decision Strategyzestaw do Affirmative. Ma również 3 zasady, w których każda z nich ocenia:
   • true
   • false
   • false

Ponieważ jedna z zasad jest ustawiona na true, Permission Onejest ustawiona na true(Twierdząca - tylko 1 musi być true).

2. Permission Twoma Decision Strategyzestaw Unanimousz 2 zasadami:
   • true
   • false

W tym przypadku Permission Twojest tak, falseponieważ jedna zasada jest fałszywa (jednogłośnie - wszystkie muszą być true).

3. Teraz nadchodzi ostateczna ocena. Jeśli serwer zasobów Decision Strategyjest ustawiony na Affirmative, dostęp do tego zasobu zostanie przyznany, ponieważPermission One jest true. Jeśli z drugiej strony serwer zasobów Decision Strategyjest ustawiony na Unanimous, dostęp byłby zabroniony.

Widzieć:

• Ustawienia serwera zasobów
• Zarządzanie uprawnieniami

Będziemy to ponownie odwiedzać. Wyjaśniam, jak ustawić serwer zasobówDecision Strategy W części II .

więc na przykład mógłbym mieć pozwolenie na dostęp do „kont” i pozwolenie na zakres „widok”, więc miałbym uprawnienia do przeglądania kont?

Krótka odpowiedź brzmi: tak. Teraz rozwińmy to trochę :)

Jeśli masz następujący scenariusz:

1. Serwer zasobów jest Decision Strategyustawiony na UnanimouslubAffirmative
2. Uprawnienie do dostępu do account/{id}zasobu totrue
3. Uprawnienie do dostępu do viewzakresu totrue

Otrzymasz dostęp do przeglądania konta.

• true+ truejest równe truepod Affirmativelub Unanimous Decision Strategy.

Teraz, jeśli to masz

1. Serwer zasobów jest Decision Strategyustawiony naAffirmative
2. Uprawnienie do dostępu do account/{id}zasobu totrue
3. Uprawnienie do dostępu do viewzakresu tofalse

Otrzymasz również dostęp do przeglądania konta.

• true+ falsejest truew ramach Affirmativestrategii.

Chodzi o to, że dostęp do danego zasobu zależy również od twojej konfiguracji, więc bądź ostrożny, ponieważ możesz nie chcieć drugiego scenariusza.

Ale czy mam rację, że to oznacza, że ​​potrzebuję polityki dla każdej starszej grupy, do której mógłby należeć użytkownik?

Nie jestem pewien, jak Keycloak zachowywał się 2 lata temu, ale możesz określić zasady oparte na grupach i po prostu dodać wszystkie swoje grupy do tej polityki. Z pewnością nie musisz tworzyć jednej polityki na grupę.

Na przykład, jeśli pełnię rolę „helpdesk”, potrzebuję zasady „członkostwa w helpdesku”, którą mogę następnie dodać do uprawnienia „viewAccount”. Czy to jest poprawne?

Dość dużo. Można to ustawić na wiele sposobów. Na przykład możesz:

1. Utwórz zasób (np. /account/{id}) I powiąż go z account:viewzakresem.
2. utwórz zasadę opartą na rolach i dodaj helpdeskrolę w ramach tej polityki
3. Utwórz Scope-Baseduprawnienie o nazwie viewAccounti powiąż je z scope, resourceipolicy

W części II ustawimy coś podobnego.

część druga

Keycloak ma zgrabne małe narzędzie, które pozwala przetestować wszystkie zasady. Co więcej, w rzeczywistości nie trzeba uruchamiać kolejnego serwera aplikacji i wdrażać oddzielnej aplikacji, aby to zadziałało.

Oto scenariusz, który skonfigurujemy:

1. Stworzymy nowe królestwo o nazwie stackoverflow-demo
2. Stworzymy bank-apiklienta w tym królestwie
3. Zdefiniujemy zasób wywoływany /account/{id}dla tego klienta
4. account/{id}Będzie miał account:viewzakres
5. Stworzymy użytkownika o nazwie bobw nowej dziedzinie
6. Będziemy także tworzyć trzy role: bank_teller, account_owneriuser
   • Nie będziemy kojarzyć się bobz żadnymi rolami. Nie jest to teraz potrzebne.
7. Skonfigurujemy następujące dwie Role-Basedzasady:
   • bank_telleri account_ownermieć dostęp do /account/{id}zasobu
   • account_ownerma dostęp do account:viewzakresu
   • user nie ma dostępu do zasobu lub zakresu
8. Będziemy bawić się Evaluatenarzędziem, aby zobaczyć, jak można przyznać lub odmówić dostępu.

Wybaczcie, ten przykład jest nierealny, ale nie znam sektora bankowego :)

Konfiguracja Keycloak

Pobierz i uruchom Keycloak

cd tmp
wget https://downloads.jboss.org/keycloak/8.0.0/keycloak-8.0.0.zip 
unzip keycloak-8.0.0.zip
cd keycloak-8.0.0/bin
./standalone.sh 

Utwórz początkowego administratora

1. Iść do http://localhost:8080/auth
2. Kliknij na Administration Console łącze
3. Utwórz administratora i zaloguj się

Odwiedź stronę Pierwsze kroki , aby uzyskać więcej informacji. Do naszych celów wystarczy powyższe.

Przygotowanie sceny

Stwórz nowe królestwo

1. Najedź myszką po masterkrólestwie i kliknijAdd Realm przycisk.
2. Wchodzić stackoverflow-demo jako nazwę.
3. Kliknij Create .
4. W lewym górnym rogu powinno być teraz napisane stackoverflow-demozamiast mastersfery.

Zobacz Tworzenie nowego królestwa

Utwórz nowego użytkownika

1. Kliknij Userslink po lewej stronie
2. Kliknij Add Userprzycisk
3. Wpisz username(np. bob)
4. Upewnij się, że User Enabledjest włączony
5. Kliknij Save

Zobacz Tworzenie nowego użytkownika

Utwórz nowe role

1. Kliknij Rolesłącze
2. Kliknij Add Role
3. Dodaj następujące role: bank_teller, account_owneriuser

Ponownie, nie kojarz swojego użytkownika z rolami. Dla naszych celów nie jest to potrzebne.

Zobacz role

Utwórz klienta

1. Kliknij Clientsłącze
2. Kliknij Create
3. Wejdź bank-apidoClient ID
4. Do Root URLwejściahttp://127.0.0.1:8080/bank-api
5. Kliknij Save
6. Upewnij się, że Client Protocoltakopenid-connect
7. Zmień Access Typenaconfidential
8. Zmień Authorization EnablednaOn
9. Przewiń w dół i naciśnij Save. NowyAuthorization górze powinna pojawić się karta.
10. Kliknij Authorizationkartę, a następnieSettings
11. Upewnij się, że Decision Strategyjest ustawiony naUnanimous
    • To jest serwer zasobów Decision Strategy

Widzieć:

• Tworzenie aplikacji klienckiej
• Włączanie usług autoryzacyjnych

Utwórz niestandardowe zakresy

1. Kliknij Authorizationkartę
2. Kliknij Authorization Scopes>, Createaby wyświetlić Add Scopestronę
3. Wpisz account:viewnazwę i naciśnij Enter.

Utwórz „Wyświetl zasoby konta”

1. Kliknij Authorizationlink powyżej
2. Kliknij Resources
3. Kliknij Create
4. Wpisz View Account Resourcezarówno, jak NameiDisplay name
5. Wejdź account/{id}doURI
6. Wpisz account:vieww polu Scopestekstowym
7. Kliknij Save

Zobacz Tworzenie zasobów

Utwórz swoje zasady

1. Ponownie w Authorizationzakładce kliknijPolicies
2. Wybierz RolezCreate Policy rozwijanej
3. W Namesekcji wpiszOnly Bank Teller and Account Owner Policy
4. W obszarze Realm Roleswybierz zarówno rolę, jak bank_telleriaccount_owner
5. Upewnij się, że Logicjest ustawiona naPositive
6. Kliknij Save
7. KliknijPolicies łącze
8. Wybierz Roleponownie z listy Create Policyrozwijanej.
9. Tym razem użyj Only Account Owner PolicydlaName
10. Pod Realm Roleswybierzaccount_owner
11. Upewnij się, że Logicjest ustawiona naPositive
12. Kliknij Save
13. Kliknij Policieslink u góry, powinieneś zobaczyć nowo utworzone zasady.

Zobacz Zasady oparte na rolach

Zwróć uwagę, że Keycloak ma znacznie silniejsze zasady. Zobacz Zarządzanie zasadami

Utwórz uprawnienie oparte na zasobach

1. Ponownie w Authorizationzakładce kliknijPermissions
2. Wybierz Resource-Based
3. Wpisz View Account Resource PermissiondlaName
4. Pod ResourcestypemView Account Resource Permission
5. Pod Apply PolicywybierzOnly Bank Teller and Account Owner Policy
6. Upewnij się, że Decision Strategyjest ustawiony naUnanimous
7. Kliknij Save

Zobacz Tworzenie uprawnień opartych na zasobach

Uff ...

Ocena uprawnienia opartego na zasobach

1. Ponownie na Authorizationkarcie wybierzEvaluate
2. Pod Userwejściembob
3. Pod Roleswybierzuser
   • Tutaj będziemy kojarzyć naszego użytkownika z naszymi utworzonymi rolami.
4. Pod Resourceswybierz View Account Resourcei kliknijAdd
5. Kliknij Oceń.
6. Rozwiń, View Account Resource with scopes [account:view]aby zobaczyć wyniki i powinieneś zobaczyć DENY.

7. Ma to sens, ponieważ zezwalamy tylko dwóm rolom na dostęp do tego zasobu za pośrednictwem Only Bank Teller and Account Owner Policy. Przetestujmy to, aby upewnić się, że to prawda!
8. Kliknij Backlink tuż nad wynikiem oceny
9. Zmień rolę boba na account_owneri kliknij Evaluate. Powinieneś teraz zobaczyć wynik jako PERMIT. To samo, jeśli wrócisz i zmienisz rolę nabank_teller

Zobacz Ocenianie i testowanie zasad

Utwórz uprawnienie oparte na zakresie

1. Wróć do Permissionssekcji
2. Wybierz Scope-Basedten czas z listy Create Permissionrozwijanej.
3. Pod Name, wprowadźView Account Scope Permission
4. Pod Scopes, wprowadźaccount:view
5. Pod Apply Policy, wprowadźOnly Account Owner Policy
6. Upewnij się, że Decision Strategyjest ustawiony naUnanimous
7. Kliknij Save

Zobacz Tworzenie uprawnień opartych na zakresie

Drugi przebieg próbny

Ocena naszych nowych zmian

1. Wróć do Authorizationsekcji
2. Kliknij Evaluate
3. Użytkownik powinien być bob
4. Role powinny być bank_teller
5. Zasoby powinny być View Account Resourcei kliknijAdd
6. Kliknij Evaluatei powinniśmy dostać DENY.
   • Ponownie nie powinno to być zaskoczeniem, ponieważ bank_tellerma dostęp do, resourceale nie scope. Tutaj jedno zezwolenie jest oceniane jako prawdziwe, a drugie jako fałszywe. Biorąc pod uwagę, że serwer zasobów Decision Strategyjest ustawiony na Unanimous, ostateczną decyzją jest DENY.
7. Kliknij na Settingspod Authorizationzakładki i zmienić Decision Strategysię Affirmativei wrócić do kroków 1-6 ponownie. Tym razem ostateczny wynik powinien być PERMIT(jedno zezwolenie jest prawdziwe, więc ostateczna decyzja jest prawdziwa).
8. Ze względu na kompletność przełącz serwer zasobów z Decision Strategypowrotem na Unanimous. Ponownie wróć do kroków od 1 do 6, ale tym razem ustaw rolę jako account_owner. Tym razem ostateczny wynik jest znowu PERMITsensowny, biorąc pod uwagę, że account_ownerma dostęp zarówno do, jak resourcei scope.

Schludnie :) Mam nadzieję, że to pomoże.

Chciałem wymusić autoryzację za pomocą czystych metod HTTP, bez użycia adaptera, ponieważ Lua nie miał adaptera. Mam nadzieję, że ta odpowiedź pomoże ludziom szukającym metody innej niż adapter.

Jeśli szukasz adaptera, najlepszym miejscem na rozpoczęcie jest skrócona instrukcja obsługi . Szczególnie przykład autoryzacji rozruchu sprężynowego .

W przypadku implementacji opartej wyłącznie na protokole HTTP:

Krok 1:

Zdefiniuj zasady i uprawnienia w interfejsie administratora Keycloak

Krok 2

Miej wewnętrzne mapowanie, które ścieżki HTTP należą do których zasobów i wymagane zakresy dla każdej ścieżki. Można to również zapisać w pliku konfiguracyjnym . Po wywołaniu określonej trasy wywołaj punkt końcowy tokenu Keycloak, aby sprawdzić poprawność oświadczeń tokenu dostępu.

{
  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING"
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      }
    ]
  }
}

Jeśli używasz adaptera i nie określisz ścieżki ani zasobu, adapter wewnętrznie wyszuka ścieżki i zasoby z Keycloak .

Krok 3:

Użyj punktu końcowego tokenu, aby uzyskać lub ocenić uprawnienia. Możesz użyć response_modeparametru, aby uzyskać ostateczną decyzję (czy przyznać dostęp) lub pobrać całe uprawnienia.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "permission=Resource A#Scope A"

Jeśli żądanie autoryzacji nie jest mapowane na żadne uprawnienie, 403zamiast tego zwracany jest kod stanu HTTP.