Передній план
Ми переходимо від монолітної платформи до більш сервісно орієнтованої архітектури. Ми застосовуємо дуже основні принципи DDD і розділяємо наш домен на різні обмежені контексти. Кожен домен поширюється та надає послугу через веб-API (REST).
Через характер нашої діяльності у нас є такі послуги, як бронювання , послуги , клієнти , товари тощо.
Ми також створили сервер ідентичності (на основі Thinktecture Identity Server 3), головна роль якого:
- Централізуйте аутентифікацію (даючи облікові дані, які вона видає маркери)
- Додайте претензії в маркери, такі як: область застосування клієнта (під клієнтом я маю на увазі додаток, який робить запит), ідентифікатор клієнта (під клієнтом я маю на увазі особу, яка використовує додаток)
Ми також представили роль API шлюзу, який централізує зовнішній доступ до наших послуг. Шлюз API забезпечує функції, які не потребують глибокого знання внутрішніх доменів, таких як:
- Зворотний проксі: маршрутизує вхідні запити у відповідну внутрішню службу
- Версія: версія API шлюзу API відображає різні версії внутрішніх служб
- Аутентифікація: клієнтські запити включають маркер, виданий сервером ідентичності, і шлюз API перевіряє маркер (переконайтеся, що користувач говорить, хто це є)
- Дроселювання: обмеження кількості запитів на кожного клієнта
Авторизація
Що стосується авторизації, цим керується не в шлюзі API, а у внутрішніх службах. Зараз ми робимо два основних типи дозволів:
- Авторизація на основі обсягів клієнта. Приклад: клієнт (зовнішню програму споживаючи наші інтерфейси API) вимагає , щоб область дії «замовлення» для доступу до Замовлення служби API кінцевих точок
- Авторизація на основі замовника. Приклад: лише якщо клієнт (фізична особа, яка користується програмою) є учасником бронювання, може отримати доступ до кінцевої точки GET / бронювання з сервісу " Замовлення".
Щоб мати змогу обробляти авторизацію у внутрішніх службах, шлюз API просто пересилає маркер (при маршрутизації запиту до внутрішньої служби), що включає як інформацію про клієнта (додаток, що робить запит), так і клієнта як претензію (в ті випадки, коли людина реєструється у клієнтській програмі).
Опис проблеми
Поки що добре, поки ми не запровадили міжпослужний зв’язок (деякі сервіси можуть спілкуватися з іншими службами для отримання деяких даних).
Питання
Як слід підходити до авторизації в міжслужбових комунікаціях?
Розглянуті варіанти
Для обговорення різних варіантів я буду використовувати наступний зразок сценарію:
- У нас є зовнішня програма під назвою ExternalApp, яка звертається до нашого API ( ExternalApp може розглядатися як клієнт ) для того, щоб створити потік бронювання
- ExternalApp потребує доступу до служби " Бронювання" , тому ми надаємо ExternalApp сферу "бронювання"
- Внутрішньо (це щось абсолютно прозоре для ExternalApp ) послуга " Бронювання" отримує доступ до служби " Сервіс" для отримання послуг за замовчуванням бронювання, таких як рейси, страхування або прокат автомобілів.
Під час внутрішнього обговорення цього питання з'явилося кілька варіантів, але ми не впевнені, який варіант найкращий:
- Коли Bookings спілкується зі службами , він повинен просто переслати початковий маркер, який він отримав від шлюзу API (вказуючи, що клієнтом є ExternalApp )
- Наслідки: нам може знадобитися надати області ExternalApp, які не повинні були надаватися. Приклад: ExternalApp, можливо, повинен мати як "бронювання", так і "послуги", тоді як тільки "бронювання" може бути достатньо
- Коли Bookings зв’язується із Сервісами , він пересилає маркер, який вказує, що клієнт тепер став Bookings (замість ExternalApp ) + додає претензію, яка вказує, що Bookings вказує на оригінального клієнта ExternalApp
- Також включає інформацію про те , що оригінальний клієнт є ExternalApp на послуги служба може також зробити логіку таких як фільтрувати деякі послуги в залежності від вихідного викликає абонента (наприклад , для внутрішніх додатків , ми повинні повернути все бої, для зовнішніх додатків тільки деякі)
- Служби не повинні спілкуватися між собою (тому ми навіть не повинні стикатися з цим питанням)
Заздалегідь дякую за ваш внесок.