Перейти до основного вмісту

Управління доступом

інформація

Управління доступ є ключовою складовою побудови бізнес-логіки, оскільки на основі прав доступу та ролей можливо визначити та систематизувати бізнес-процесів. Виділити підрозділи, контрагентів, постачальників, клієнтів та інші групи акторів. Виділення акторів та їх класифікація при накладі на прозорі бізнес-процес формує комплексну систему.

Елементи доступу​

Управління доступом здійснюється за допомогою елементів доступу, що є основними точками побудови прав доступу. Вони включають в себе наступне:

  • Тип приватизації: чи потрібна авторизація для доступу, чи інформація є публічною.
  • Права доступу:
    • Можливість виконувати дії або слухати події.
    • Доступ до перегляду представлень.
    • Доступ до сторінок.
  • Тип користувачів: чи є користувач людиною або системою.
  • Ролі: сутності зі списком прав доступу та їх назвами.
  • Додаткові селектори: організації, структури, підрозділи.
інформація

Створення списку прав доступу має бути автоматизованим, з врахуванням опису бізнес-схеми додатка. Цей список використовується при створенні ролей, які призначаються користувачам або системам. Також можуть бути створені окремі обмежувачі доступу, які включають прив'язку особи до організації, її структури або підрозділу, а також призначення ролі самій організації, якщо бізнес-вимоги передбачають організацію як сутність.

При описі конкретних дій, подій, представлень та сторінок, необхідно вказати тип доступу, обробкою якого займається системна частина кодової бази.

порада

Розглядаючи бізнес-вимоги до реєстрації організацій X-Fiber, підходить до цього процесу як до реєстрації користувачів. Лише з тією різницею, що ми маємо справу з юридичними, а не фізичними особами.

Зберігання інформації​

інформація

У керуванні доступом існують два типи зберігання інформації про надання та керування доступом: постійне та тимчасове. Постійне зберігання здійснюється через створення записів у відповідних таблицях або колекціях бази даних, тоді як тимчасове забезпечується через зберігання їх у пам'яті або NoSQL базах даних, наприклад, Redis, з можливістю швидкого доступу.

Одночасне використання обох підходів вносить додаткову складність у реалізацію, оскільки потрібно описати функціонал для створення та зміни прав як у Redis, так і в базі даних. Проте це дозволяє значно зменшити навантаження на базу даних, оскільки ролі та права доступу формуються на етапі створення веб-застосунку і рідко змінюються в подальшому.

Механізми​

Для чіткого розуміння роботи керування доступом опишемо ряд базових сценаріїв роботи з управління доступом.

1. Отримання токенів доступу:

  1. Користувач вводить свої облікові дані (логін та пароль) на сторінці авторизації системи або здійснює авторизації іншої стратегією авторизації.
  2. Система перевіряє ці дані на відповідність збереженим обліковим записам у базі даних. Якщо введені дані є правильними, кінцевий маршрут логування створює токен доступу та рефреш-токен для цього користувача.
  3. Створені токени передаються клієнту (наприклад, у вигляді куки або заголовка авторизації).
  4. Користувач отримує доступ до ресурсів системи за допомогою цих токенів.
  5. Токени можуть мати обмежений термін дії. Після закінчення терміну дії токену доступу, користувач повинен повторно увійти до системи.

2.Оновлення ролі у користувача:

  1. При зміні ролі користувача у користувача з однієї на іншу, та при отримані запиту від користувача з застарілою ролю система створює новий токен доступу та рефреш-токен.
  2. Старі токени, які були видані до оновлення ролі, перевіряються під час надходження запитів на сервер. Якщо старий токен все ще активний, але його роль більше не відповідає новим правам доступу, сервер повертає статус 403 та надає рефреш токен.
  3. Коли клієнт отримує відповідь про те, що токен не є валідним через зміну ролі, він повинен запросити новий токен за допомогою рефреш-токена.
  4. Система перевіряє валідність рефреш-токена та перевіряє, чи має користувач права на оновлення токенів. Якщо так, то видається новий токен доступу та оновлений рефреш-токен.

3. Оновлення права доступу у ролі:

  1. Коли права доступу до ролі змінюються, ця інформація оновлюється в базі даних та Redis сховищі.
  2. При надходженні запиту на сервер, токен перевіряється на валідність. Якщо токен валідний та відбувається перевірки наявності у цієї ролі прав доступу у сховищі Redis.
  3. Якщо ні, то повертається 403 помилка з текстом помилки, якщо так - запит коректно відпрацьовує.

4. Створення нової ролі:

  1. Створення нової ролі та прикріплення до неї прав доступу.
  2. Присвоєння нової ролі необхідній групі користувачів
  3. Здійснюється оновлення ролі у користувача за сценарієм №2.

5. Перше завантаження веб-сервера:

  1. Здійснюється запит до бази даних для отримання всіх ролей доступу.
  2. Вивантаження ролей доступу та відповідниї їх прав доступу до Redis.
  3. Створення сповіщення про завершення завантаження ролей в Redis.
warning

Ролі та права доступу входять до абстрактних предметних областей, що широко використовуються у веб-застосунках. В майбутніх релізах X-Fiber планує надавати точкові рішення через агента базових операцій baseAgent, або можливість інтеграції предметних областей як NPM пакетів.

6. Перевірка прав доступу веб-клієнта:

  1. При відкритті дисплея відправляти JWT токен на спеціалізований кінцевий маршрут.
  2. Веб-сервер віддає перелік дисплеїв до якої у ролі є права доступу та хеш відповіді.
  3. Відбувається показ дисплеїв в залежності від їх наявності в повернуто переліку дисплеїв.
  4. При повторних перевірки надсилається хеш для порівняння.