Założenia mechanizmu uprawnień

Założenia mechanizmu:

1. Możliwość nadania uprawnień do konkretnych typów spraw. W przypadku gdy rola użytkownika wymaga uprawnienia do wszystkich typów spraw, aby rozwiązać problem związany z uciążliwego definiowania wielu powiązań, wprowadza się znak * reprezentujący wszystkie typy dostępne w bazie danych.
2. Możliwość nadania uprawnień do konkretnych parametrów (pól) danego typu sprawy. W przypadku gdy rola użytkownika wymaga uprawnienia do wszystkich pól sprawy, aby rozwiązać problem związany z uciążliwego definiowania wielu powiązań, wprowadza się znak * reprezentujący wszystkie pola danego typu.
3. Występują trzy poziomy uprawnień:
   1. RW (read/write) – uprawnienia odczytu i zapisu wartości
   2. RO (read only) – uprawnienia tylko do odczytu wartości
   3. WO (write only) – uprawnienia tylko do zapisu wartości – w praktyce uprawnienie sprowadza się do możliwości tylko wprowadzania nowych danych – nie ma możliwości modyfikacji danych, gdyż modyfikacja zakłada wcześniejsze odczytanie danych i uzyskanie dostępu do ich odczytu.
4. Brak uprawnień indywidualnych, bezpośrednio nadawanych użytkownikom. Uprawnienia dostępu do danych użytkownicy uzyskują za pośrednictwem posiadanych ról.
5. Mechanizm nie pełni roli mechanizmu uwierzytelniającego. To systemy zewnętrzne mają realizować zadanie identyfikacji użytkownika i przypisać mu odpowiednie role. Mechanizm jedynie autoryzuje dostęp do danych, weryfikuje, czy zestaw ról posiadanych przez użytkownika spełnia wymagania dotyczące dostępu do danych.

Mechanizm uprawnień

Mechanizm uprawnień oparty jest o encje składowane w relacyjnej bazie danych:

• TypeParamRole – powiązanie typu, jego pól z uprawnieniem oraz rolą użytkownika jaką pełni.
• Role – lista ról, którym nadawane są odpowiednie uprawnienia
• Case – obiekty spraw posiadają pola informujące o tym jaka rola użytkownika została wykorzystana podczas wprowadzania zmian:
  • createdByRoleName – pole z nazwą roli, którą pełnił użytkownik podczas dodawania sprawy.
  • lastModifiedByRoleName – pole z nazwą roli, którą pełnił użytkownik podczas modyfikacji sprawy

Kontekst operacji

Dane użytkownika, jego nazwa, nazwa roli domyślnej, oraz zestaw ról przekazywany jest do mechanizmu weryfikacji uprawnień za pośrednictwem obiektu Context (MrcContext). Obiekt kontekstu jest wymagany podczas wywoływania wszelkich usług SOAP/REST systemu i koniecznym jest zdefiniowanie następujących jego parametrów:

Przykład danych kontekstu w usłudze REST:

Algorytm działania mechanizmu

Poniżej przedstawiono algorytm działania mechanizmu:

Pobranie uprawnień użytkownika

Podczas akcji pobierania uprawnień użytkownika wykonywane są następujące operacje:

1. Odczyt danych użytkownika z obiektu kontekstu żądania SOAP/REST
2. Jeżeli system zewnętrzny uzyskał połączenie do usług systemu Mercury za pośrednictwem mechanizmu OAuth, weryfikowany jest zakres (lista ról) na jaki został wystawiony token sesji. Jeżeli zakres się nie zgadza zostaje zrzucony wyjątek, o braku prawidłowego token’a sesji i że trzeba go odświeżyć.
3. Na podstawie danych z kontekstu pobierane są dostępne uprawnienia do typów i ich pól z encji TypeParamRole.
4. Budowany jest obiekt „SecurityContext” („kontekst bezpieczeństwa”) użytkownika zawierający:
   1. Listę typów, do których ma prawo zapisu
   2. Listę typów, do których ma prawo odczytu
   3. Listę parametrów w powiązaniu z typami, do których ma prawo zapisu
   4. Listę parametrów w powiązaniu z typami, do których ma prawo odczytu
   5. Identyfikator kontekstu na podstawie nazwy użytkownika i zbioru jego ról. Zbudowany obiekt zostaje przesłany do pamięci podręcznej i jest wykorzystywany wielokrotnie w ramach aktywnej sesji użytkownika. Poniżej kod budowania identyfikatora:

Autoryzacja wykonywanej operacji

Na podstawie kontekstu bezpieczeństwa, w zależności od wykonywanej operacji weryfikowane są uprawnienia do wykonywania operacji na obiektach sprawy:

1. Dla operacji wyszukiwania weryfikowana jest lista kryteriów wyszukiwania (czy użytkownik ma prawo do odczytu pól po których chce zrealizować wyszukiwanie), a lista znalezionych spraw prezentowana jest w zależności od tego do jakich pól użytkownik ma uprawnienia. Jeżeli kryteria wyszukiwania nie zawierają kryterium dotyczącego typu sprawy, to zostanie ono automatycznie dodane na podstawie danych składowanych w kontekście bezpieczeństwa użytkownika (nie dotyczy sytuacji gdy użytkownik ma uprawnienia do wszystkich typów spraw).
2. Dla operacji pobierania obiektu sprawy:
   1. Czy użytkownik ma prawo do pobrania danego typu sprawy?
   2. Zwracane są tylko wartości tych parametrów, których użytkownik ma prawo odczytu
3. Dla operacji zmiany obiektu sprawy:
   1. Czy użytkownik ma prawo do zapisu danego typu sprawy?
   2. Czy użytkownik ma prawo do zapisu danego pola typu sprawy?

TypeParamRole

Encja wiążąca uprawnienia z typami, nazwami ich pól oraz rolami użytkowników.

Przykład zawartości tabeli reprezentującej dane encji w relacyjnej bazie danych:

Role

Encja ról użytkowników.