Чи повинні користуватися мікросервісами?

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

У нас є такі вимоги:

1. Користувачів слід обмежувати виконувати певні ролі. наприклад, користувач повинен мати можливість створювати / змінювати / читати вміст, який йому належить.

2. Мікросервіси повинні бути обмежені лише необхідними дозволами. наприклад, мікросервіс, який потребує лише зчитування даних з іншої служби, повинен бути явно заборонений у записі даних до цієї служби.

Наприклад, припустимо, що у нас є система, де користувачі можуть завантажувати зображення в сервіс зберігання зображень. У нас є служба розмітки тегів, яка автоматично позначає зображення на місці розташування. Користувачі можуть лише CRUD власні фотографії. Служба розмітки тегів може читати будь-яке зображення у службі зберігання зображень, однак не має змоги змінювати / видаляти.

Який хороший спосіб досягти вищезазначеного за допомогою жетонів JWT? Деякі рішення, про які ми говорили:

1. Служба зберігання зображень відкриває 2 API, один, який доступний зовні (надання користувачеві CRUD доступу) та той, який доступний всередині (надання внутрішнього доступу лише для читання). Здається негнучким - що робити, якщо інша внутрішня служба потребує доступу до читання / запису до всіх зображень (наприклад, до того, що автоматично видаляє явні зображення)?

2. Ми встановили два права доступу в JWT користувача, один - CRUD_OwnImages, а другий - READ_ForAnalysis. Служба розмітки тегів може побачити, чи має користувач READ_ForAnalysis дозволів, і якщо так, подайте відповідний запит. У нас є ще одна мікросервіс, який перевіряє, чи є у користувача CRUD_OwnImages для операцій CRUD на власних зображеннях користувача. Це покладає на кожну мікросервіс відповідальність за те, щоб користувач обмежився необхідними йому діями. У магазині зображень немає способу обмежити кожен мікросервіс таким підходом, тому він потенційно може лускатись і схильний до помилок.

3. Ми надаємо мітковій мітці власний користувач, з дозволом READ_ForAnalysis. Потім, коли служба тегування запитує зображення з магазину зображень, їй надається доступ до них, але забороняється змінювати їх. Користувач користувача має лише дозвіл CRUD_OwnImages, тому він може отримати та отримати доступ лише до своїх зображень із фронта. Якщо інша служба потребує CRUD для всіх даних, ми можемо надати її CRUD_AllData або подібні. Нам подобається такий підхід, оскільки кожна служба зараз відповідає за власні дані (а не за те, що логіка дублюється в декількох службах), але що робити, якщо для служби потрібні як користувацькі, так і дозволи мікросервісу? Чи можемо ми надійно надсилати два маркери JWT (як користувача, так і мікросервісу)? Чи існує спосіб безпечно поєднати дозволи та надіслати їх? напр

Проблема посилюється, якщо інформація користувача потрібна далі за течією (2 або 3 мікросервіси). Чи ми просто припускаємо, що окремі мікросервіси повинні обмежуватись необхідними їм діями, а не робити це явним?

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

І взагалі, у вас є три різновиди сценаріїв з мікропослугами:

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

2. Користувач заходить, завантажує фотографію, і її потрібно позначити ... але не зараз. Класно. Тепер ви обробляєте фотографію як звичайну. Пізніше, коли трапляється тег (обробка подій / повідомлення, обробка команд у стилі CQRS, деяка періодична обробка завдань, будь-яка інша), служба розмітки тегів буде представляти себе користувачеві (швидше за все, використовуючи загальний секрет для запиту користувальницького JWT від auth), а потім зробіть суб-операція від імені вихідного запитувача (з усіма їх дозволами та обмеженнями). У цього методу є звичайна проблема з асинхронними операціями, коли важко повернути користувачеві помилки, якщо справи не йдуть гладко, але якщо ви використовуєте цю схему для операцій міжсервісного обслуговування, ви б це вже вирішили.

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

Що використовувати, буде залежати від вашого сценарію, ваших потреб та вашої толерантності до ризику. І звичайно, це лише неповна сукупність узагальнень із широким штрихом.

Але в цілому самі мікросервіси не повинні бути користувачами.