kleindan.dev

Autoryzacja użytkowników

Wideo towarzyszące

Co wolno użytkownikowi?

Autoryzacja to proces upewniania się, że dany użytkownik może wykonać jakąś akcję w systemie informatycznym. Przykładów takich decyzji jest wiele, w zależności od systemu nad którym pracujemy, być może będziemy musieli zdecydować, czy użytkownik może:

W każdej jednej aplikacji internetowej będą istniały dziesiątki takich decyzji, być może nad niektórymi nawet się nie będziemy dłużej zastanawiać.

Złota zasada uprawnień użytkownika: deny by default

Eksperci od bezpieczeństwa systemów informatycznych od lat powtarzają, że domyślną polityką dostępu do jakiejkolwiek części systemu informatycznego powinna być odmowa. Po angielsku takie podejście nazywamy deny by default. Fakt, że powtarzają to od lat oznacza, że w praktyce większość zainteresowanych tego nie przestrzega. Dlaczego? Ponieważ poprawne podejście jest pracochłonne i prowadzi często do nieprzyjaznego doświadczenia użytkownika.

Czy korzystanie z systemu, w którym muszę prosić o zgodę na dostęp do każdego zakamarka systemu będzie przyjemne? Czy programowanie takiego systemu będzie łatwe? Czy notoryczne przyznawaniem minimalnie większych uprawnień pojedynczym użytkownikom będzie przyjemnym zadaniem? Absolutnie nie, szczególnie jeżeli sam utrudnię sobie życie stosując skomplikowane zasady dostępu do zasobów w systemie.

Dlatego czasem programiści i administratorzy systemów wybierają łatwiejszą ścieżkę i domyślnie przyznają użytkownikom zbyt duże uprawnienia i nie budują systemu w taki sposób, aby umożliwić bardziej precyzyjną kontrolę nad działaniami użytkowników.

Zaprojektowanie systemu, który będzie jednocześnie bezpieczny i wygodny w użyciu graniczy z cudem, ponieważ wygoda i bezpieczeństwo stoją często w opozycji. Ale poddanie się nie jest rozwiązaniem. Zacznijmy od zapoznania się z tematem.

Rodzaje autoryzacji

Autoryzacja, czyli weryfikacja, że użytkownik ma prawo wykonań akcję w systemie często wiąże się z pojęciem kontroli dostępu (ang. access control). W ciągu rozwoju systemów informatycznych wyłoniły się trzy główne kategorie systemów kontroli dostępu.

Role-Based Access Control (RBAC)

W systemach stosujących RBAC uprawnienia są powiązane z rolami, a następnie przypisujemy użytkowników do odpowiednich ról. W prawie każdym systemie można wyróżnić rolę administratora. W przypadku portalu informacyjnego możemy sobie wyobrazić rolę autorów, korektorów, redaktorów, etc. W przypadku systemu obsługującego sklep internetowy prawdopodobnie będzie można wyznaczyć rolę pracownika magazynu, wsparcia klienta, etc. Jeżeli wydaje się to intuicyjne, to dobrze, bo tak właśnie jest.

Problem w tym, że jeżeli nie wprowadzimy innych sposobów kontroli dostępu, to ciężko wprowadzić tu zniuansowane zasady. Jeżeli chcemy żeby autor w portalu infgormacyjnym mógł edytować artykuły, to na podstawie samej roli ciężko ograniczyć dostęp tylko do artykułów jego autorstwa. Możemy wprowadzić osobne role dla różnych działów albo nawet dla poszczególnych autorów, ale wtedy to się zaczyna mijać z celem.

Jeżeli chcemy ograniczyć możliwości pracowników sklepu do czasu ukończenia przez nich jakiegoś szkolenia, to znów możemy wprowadzić dodatkową rolę dla pracowników nieprzeszkolonych, ale co jeżeli mamy kilka szkoleń uprawniających do korzystania z różnych części systemu? Liczba ról szybko się rozrasta i prędzej czy później korzystanie z systemu będzie powodowało więcej problemów niż pożytku.

Attribute-Based Access Control (ABAC)

Poniekąd rozwinięciem idei kontroli dostępu na bazie roli, jest dostęp na bazie atrybutów. Atrybutem obiektu możemy nazwać dowolną parę nazwa:wartość. W przypadku użytkowników może to być “rola:administrator”, ale możemy też wybrać dowolne inne informacje, takie jak data utworzenia konta, data ostatniej aktywności, ukończone szkolenia, itd. Atrybuty możemy przypisywać nie tylko do użytkowników: w przypadku portalu informacyjnego możemy np. przypisać atrybuty związane ze stanem korekty do artykułów, itd.

Ponieważ atrybuty są bardziej elastycznym konceptem, na ich podstawie możemy wprowadzić bardziej zniuansowane reguły dostępu do zasobów systemu.

Relationship-Base Access Control (ReBAC)

Kolejnym rodzajem kontroli dostępu jest kontrola na podstawie relacji pomiędzy użytkownikiem a zasobem, do którego użytkownik próbuje się dostać. W przypadku serwisów pozwalających użytkownikom na dodawanie komentarzy często możemy edytować swoje wypowiedzi, ale z oczywistych względów nie możemy edytować komentarzy innych użytkowników. Innymi przykładami jest możliwość edycji artykułów albo postów własnego autorstwa, usuwanie dodanych przez siebie zdjęć, itd. W przypadku nieco bardziej złożonych relacji możemy, na przykład, pozwolić magazynierowi sklepu zmieniać stan magazynowy na stronie, pod warunkiem że zmiany dotyczą produktów dostępnych w magazynie do którego magazynier jest przypisany, a nie w każdym innym magazynie obecnym w systemie.

Zadanie praktyczne

W repozytorium z kodem do naszych zajęć w podfolderze lekcja15 znajduje się implementacja, w której uzależniliśmy dostęp do niektórych podstron od tego, czy użytkownik jest zalogowany, czy nie.

Na następnej lekcji przejdziemy pokażę swoje rozwiązanie powyższych problemów i zastanowimy się nad alternatywnymi podejściami do tych tematów.

Łączenie handlerów w łańcuchy

Podczas konfigurowania handlerów dla ścieżek w naszej aplikacji Express dotychczas zawsze definiowaliśmy pojedynczą funkcję będącą handlerem. Express pozwala na dodanie dla pojedynczej ścieżki wielu handlerów - w takim przypadku są one uruchamiane w kolejności dodania i każdy z nich może albo przekazać żądanie do kolejnego handlera poprzez wywołanie funkcji przekazanej do niego jako argument next przed wyjściem, albo obsłużenie żądania samodzielnie. W tej lekcji wykorzystaliśmy tę technikę aby potencjalnie przekierować niezalogowanych użytkowników do formularza logowania dla ścieżek które mają być dla nich niedostępne.