Система авторизації та аутентифікації для мікросервісів та споживачів

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

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

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

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

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

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

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

Чи хороша ця делегація?

Автентифікація та авторизація - це завжди хороші теми

Я спробую пояснити вам, як ми маємо справу з авторизаціями в поточній службі, яка працює у багатьох орендарях, що я працюю. Аутентифікація та авторизація засновані на лексемах, використовуючи відкритий стандарт JSON Web Token. Послуга пропонує API REST, до якого можуть отримати доступ будь-який клієнт (веб, мобільні та настільні програми). Після успішної автентифікації користувача сервіс надає маркер доступу, який необхідно надсилати при кожному запиті на сервер.

Тож дозвольте мені представити деякі поняття, які ми використовуємо на основі того, як ми сприймаємо та обробляємо дані на серверній програмі.

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

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Тож скажімо, що поки що у нас є три ресурси в нашій службі; product, paymentі order.

Дія : це операція, яку можна виконати на ресурсі, наприклад, читати, створювати, оновлювати, видаляти і т. Д. Це не обов'язково, щоб бути лише класичними операціями CRUD. Ви можете виконати дію з ім'ям follow, наприклад, якщо хочу відкрити службу, яка поширює якусь інформацію за допомогою WebSockets.

Здатність : здатність виконувати actionна a resource. Наприклад; читати продукти, створювати продукти тощо. Це в основному лише пара ресурсів / дій. Але ви можете також додати ім’я та опис.

Роль : Набір здібностей, якими користувач може володіти. Наприклад, роль Cashierможе мати можливості "читати платіж", "створювати платіж" або роль Sellerможе мати здібності "читати товар", "замовлення на читання", "порядок оновлення", "видалити замовлення".

Нарешті, користувач може мати різні ролі, призначені йому.

Пояснення

Як я вже говорив раніше, ми використовуємо JSON Web Token, а можливості, якими користувач володіє, оголошуються у корисному навантаженні маркера. Отже, припустимо, у нас є користувач із ролями касира та продавця одночасно для невеликого роздрібного магазину. Корисне навантаження буде виглядати приблизно так:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

Як ви бачите у scopesпретензії, ми не вказуємо назву ролей (касир, продавець), натомість визначаються лише ресурси та дії, які стосуються. Коли клієнт надсилає запит до кінцевої точки, сервіс повинен перевірити, чи містить маркер доступу ресурс та необхідні дії. Наприклад, GETзапит до кінцевої точки /payments/88буде успішним, але DELETEзапит на ту саму кінцеву точку повинен бути невдалим.

• Як групувати та називати ресурси та як визначати та називати дії та здібності, буде рішенням, прийнятим розробниками.

• Які ролі та які здібності матимуть ці ролі, - це рішення, які приймаються замовниками.

Звичайно, потрібно додати додаткові властивості до корисного навантаження, щоб ідентифікувати користувача та клієнта (орендаря), який видав маркер.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

За допомогою цього методу ви можете точно налаштувати доступ будь-якого облікового запису користувача до вашої послуги. І найголовніше, що вам не потрібно створювати різні заздалегідь визначені та статичні ролі, як-от адміністратор, агенти та кінцеві користувачі, як ви вказуєте у своєму запитанні. Супер Користувач буде користувач , який володіє roleз усіма resourcesі actionsслужби , покладені на нього.

Тепер, що робити, якщо є 100 ресурсів і ми хочемо роль, яка дає доступ до всіх або майже всіх? Наш корисний набір жетонів був би величезним. Це вирішується шляхом введення ресурсів та просто додавання батьківського ресурсу в область доступу маркера.

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

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

Оскільки всі абоненти повинні надати вашим мікросервісам докази їх автентифікації, ви можете також прив’язати дозволи до цієї автентифікації. Якщо ви надаєте можливість прив’язати користувача до довільної групи доступу (або груп, якщо ви хочете пофантазувати, хоча дозволів додавати проти віднімання тут важче вирішити.), Від ваших клієнтів виникне менше запитань про те, чому користувач x змогла виконати небажану операцію. У будь-якому випадку комусь належить зробити перевірку списку доступу для кожної послуги, тож це може бути і ви. Це щось, що дуже легко було б кодувати на початку всіх послуг (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) Ви також можете це зробити і самостійно слідкувати за групами користувачів. Це правда, що вам доведеться мати менеджера групи прав дозволів і працювати з ним у користувальницькому інтерфейсі управління користувачем (використовувати наявну / створити нову групу для дозволів користувача). Визначайте список користувачів, прив'язаних до групи, коли ви редагуєте визначення, щоб уникнути плутанини. . Але це не важка робота. Просто встановіть метадані для всіх служб і зв’яжіть пошук карти між групою та службою на обробку маркерами аутентичності.

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

(Як зауваження, це все повинно статися через щось на зразок SSL або навіть двосторонній SSL, якщо ви стурбовані безпекою обох кінців розмови. Якщо ви "просочите" ці жетони до зловмисника, він перебуває так, ніби він " d зламав пароль.)

На мою думку, тут у вас є два варіанти.

• Якщо вам просто потрібно мати доступ, який можна настроювати, по суті, до тієї самої програми, тоді служби перевірте дозволи та надайте своїм клієнтам інтерфейс, який дозволяє їм змінювати дозволи, надані для кожної ролі. Це дозволяє більшості користувачів використовувати налаштування ролей за замовчуванням, у яких «проблемні» клієнти можуть налаштувати ролі або створювати нові, щоб відповідати їх потребам.

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

Розгляд безпеки

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

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

Я бачу тут дві серйозні проблеми для серйозного бізнесу:

• Що робити, якщо якийсь негідний користувач там (наприклад, в одному з заводів вашого партнера) реверсує клієнтське додаток і дізнається про API, обходить обмеження, які його компанія наклала на клієнта, і використовує цю інформацію для шкоди вашій компанії? Ваша компанія вимагатиме відшкодування збитків, але компанія, яка займається партнерством, стверджує, що ви не надали засобів для захисту своїх даних достатньо.
• Зазвичай, лише питання про час, коли конфіденційні дані будуть зловживати (або аудит виявить ризик), і ваше керівництво в кінцевому підсумку попросить більш жорстко контролювати ці дані.

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

Якщо ви продовжуєте свою посаду, проконсультуйтеся принаймні зі своїм співробітником інформаційної безпеки.

Як це здійснити

У вас є хитрість:

Таким чином нам слід було б відстежувати лише сфери токенів.

Гаразд, ви маєте намір використовувати деякі загальні маркери, обрані клієнтом. Знову слабкість у моєму оці, адже деякі клієнти можуть бути поза вашим контролем.

Я не знаю, ви вже використовуєте JWT або використовуєте якісь інші методи. Але якщо ви використовуєте JWT, у вас може бути маркер ідентичності, який відображає особу користувача (і навіть другий маркер, який надійно ідентифікує вихідний додаток, що може дозволити вам диференціювати рівень довіри між власними клієнтами та зовнішніми клієнтами ).

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

Тут є і коротка відповідь. Вам слід самостійно реалізувати всі основні функції, які ви хочете запропонувати своїм «клієнтам». Проблемним є те, щоб клієнти додавали таку принципову поведінку, як дозволи користувачів, оскільки ви вже робите автентифікацію користувача; якщо ви залишите його клієнту для його реалізації, ви можете "підтримувати" кілька реалізацій одного і того ж коду дозволів. Незважаючи на те, що ви не володієте ним, у їхньому коді з’являться помилки, і ви хочете, щоб ваші клієнти в межах розуму мали функціонал, який вони очікували, тому ви підтримуєте вирішення проблем, які виникають у клієнта. Підтримка декількох баз коду не є цікавою.