Autoryzacja przez kontrolę dostępu

Autoryzacja to proces przyznawania dostępu do różnych części i zasobów aplikacji webowej użytkownikom. Powszechnym sposobem autoryzowania użytkowników jest kontrola dostępu, w której administrator strony definiuje, jakie uprawnienia muszą zostać przyznane użytkownikom i innym podmiotom, aby mogli uzyskać dostęp do określonych zasobów.

Autoryzacji nie należy mylić z uwierzytelnianiem, które jest procesem weryfikacji, czy użytkownik jest tym, za kogo się podaje, zazwyczaj realizowanym przez podanie danych logowania. Po uwierzytelnieniu użytkownika proces autoryzacji musi być wykonywany przy każdym żądaniu, aby upewnić się, że użytkownik ma dostęp do żądanego zasobu.

Podczas dostępu do aplikacji przez GraphQL musimy sprawdzić, czy użytkownik ma dostęp do żądanych elementów schematu. Czy logika autoryzacji powinna być zakodowana w warstwie GraphQL?

Odpowiedź brzmi: nie. Jak dokumentacja na graphql.org jasno wskazuje, logika autoryzacji należy do warstwy logiki biznesowej i stamtąd jest dostępna dla GraphQL. Dzięki temu aplikacja może mieć jedno źródło prawdy dla autoryzacji (czyli to oferowane przez WordPress):

Gato GraphQL respektuje tę zasadę, odzwierciedlając (i pod spodem delegując do) mechanizm autoryzacji zapewniany przez WordPress.

​

Polityki kontroli dostępu

Spośród kilku polityk kontroli dostępu, które możemy wdrożyć dla naszej aplikacji, dwie najpopularniejsze to kontrola dostępu oparta na rolach (RBAC) i kontrola dostępu oparta na atrybutach (ABAC).

WordPress, i Gato GraphQL, obsługują obie z nich.

Przy kontroli dostępu opartej na rolach przyznajemy uprawnienia na podstawie ról, a następnie przypisujemy role użytkownikom. Na przykład WordPress ma rolę administrator z dostępem do wszystkich zasobów, oraz role editor, author, contributor i subscriber z ograniczonymi uprawnieniami w różnym stopniu, takimi jak możliwość tworzenia i publikowania wpisu na blogu, tylko jego tworzenia, lub tylko odczytywania.

Przy kontroli dostępu opartej na atrybutach uprawnienia są przyznawane na podstawie metadanych, które można przypisać do różnych podmiotów, w tym użytkowników, zasobów i warunków środowiskowych (takich jak pora dnia lub adres IP odwiedzającego). Na przykład w WordPress, capability edit_others_posts jest używana do sprawdzenia, czy użytkownik może edytować wpisy innych użytkowników.

Ogólnie rzecz biorąc, ABAC jest preferowany nad RBAC, ponieważ pozwala nam konfigurować uprawnienia z precyzyjną kontrolą, a uprawnienie jest jednoznaczne w swoim celu.

Na przykład w WordPress, rola editor posiada capability edit_others_posts, ale możemy chcieć zezwolić osobie z rolą author na edytowanie wpisu innego autora, nie przyznając jej jednak pełnego zestawu uprawnień, jakie są przyznawane edytorowi (takich jak również usuwanie wpisów innych autorów). Dlatego przyznanie capability edit_others_posts i sprawdzanie tego warunku jest bardziej odpowiednie niż sprawdzanie roli editor.

​

Definiowanie widoczności

Gdy użytkownik nie posiada uprawnienia do dostępu do żądanego pola ze schematu GraphQL, jaki błąd powinien zostać zwrócony?

Istnieją dwie możliwości, zgodnie z pożądaną widocznością schematu: publiczna lub prywatna.

W przypadku schematu publicznego, udostępniony schemat GraphQL jest taki sam dla wszystkich użytkowników, a każde pole opisuje, jakie uprawnienia są wymagane, aby uzyskać do niego dostęp. Przy żądaniu niedostępnego pola komunikat o błędzie wyjaśni, dlaczego użytkownikowi nie udzielono dostępu.

W przypadku schematu prywatnego, schemat GraphQL jest dostosowany do każdego użytkownika i udostępniane są tylko te pola, do których on/ona ma dostęp. Przy żądaniu niedostępnego pola komunikat o błędzie stwierdzi, że pole nie istnieje.

​

Kontrola dostępu przez interfejs użytkownika

W Gato GraphQL reguły kontroli dostępu są wstrzykiwane do schematu w czasie wykonania, jako konfiguracja zdefiniowana przez użytkownika za pomocą list kontroli dostępu. Dzięki temu warstwa GraphQL będzie natychmiast odzwierciedlać zmiany polityki kontroli dostępu, bez potrzeby aktualizowania kodu lub ponownego kompilowania schematu:

Administrator strony konfiguruje ACL, wybierając:

• Pola do walidacji
• Regułę do walidacji, spośród:
  • czy użytkownik musi być zalogowany?
  • czy użytkownik musi być wylogowany?
  • czy użytkownik musi mieć określoną rolę?
  • czy użytkownik musi mieć określoną capability?
• Konfigurację specyficzną dla reguły:
  • które role?
  • które capabilities?
• Widoczność:
  • domyślna (czyli taka sama jak przypisana do schematu)?
  • publiczna?
  • prywatna?