Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
 Авторизация и права в микросервисах  [new]
spider13
Member

Откуда: https://spider13.net/
Сообщений: 960
Всем привет, при разработке системы, как хотелось бы, на микросервисах, возникло одно недопонимание.

Проблем особых нет, кроме авторизационного сервиса, точнее с множественным обращением к нему.

Например пользователь авторизировался, ему выдали JWT токен, но у каждого пользователя есть права. Для получения этих прав нужно каждый раз обращаться к авторизационному сервису...
Варианты решения:
1) Записать их в JWT токен, но при обновлении прав они применяется только после выдачи нового токена, что ни есть хорошо.
2) Общая БД, что не соответствует самой архитектуре микросервисов, да и есть сделать их как можно автономнее.
3) Каждый раз обращаться к авторизационному сервису, что ни есть хорошо при большом кол-ве запросов. Например отрисовка главного экрана приложения это обращение к 8 сервисам + взаимодейсвие между собой, и того на каждое соответствие нужно делать запрос.

Подскажите, как решить подобную проблему лучше всего? Либо почитать.
22 фев 19, 12:02    [21817174]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
ViPRos
Member

Откуда:
Сообщений: 9515
spider13,

а зачем тебе микросервисы?
22 фев 19, 12:29    [21817206]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
spider13
Member

Откуда: https://spider13.net/
Сообщений: 960
ViPRos
spider13,

а зачем тебе микросервисы?


Начинается...
Я не хочу расписывать структуру всего проекта и рассказывать почему MSA подходит для данного проекта. Давай-те оффтоп не будем разводить.

Одной из идей сейчас появилось создание промежуточного шлюза, на который будет ложится функция идентификации пользователя и прав. А после пробрасывать во внутрь уже полученные данные вместо токена.
22 фев 19, 12:37    [21817218]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
Лысый дядька
Member

Откуда:
Сообщений: 356
spider13
Подскажите, как решить подобную проблему лучше всего? Либо почитать.


Да тут на что фантазии хватит. Можно, например, кешировать права на уровне пода микросервисов.
22 фев 19, 13:40    [21817267]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
mayton
Member

Откуда: loopback
Сообщений: 40510
spider13
2) Общая БД, что не соответствует самой архитектуре микросервисов, да и есть сделать их как можно автономнее.

Общая БД имеет право на существование. Рассмотрите 3 варианта CAP по Эрику Брюверу.

P.S. Глобальный DNS как-то существует и вполне себе работает. Поинтересуйтесь как.
22 фев 19, 14:02    [21817285]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
scf
Member

Откуда:
Сообщений: 1480
Только вариант 3.

Доработать авторизационный сервис, чтобы он держал больше кол-во запросов. Например, добавив к нему распределенный in-memory кеш или быструю базу данных.

Либо - короткоживущий кеш на стороне клиента. Например, если сделать кеш с expiration 1 секунда, то мы получаем ограничение нагрузки на авторизационный сервер до 1 запрос/секунда/токен и односекундный eventual consistency
22 фев 19, 15:22    [21817393]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
spider13
Member

Откуда: https://spider13.net/
Сообщений: 960
scf,

Кеш на стороне сервиса не совсем хорошо, так как нужен expiration, т.е. при изменении прав они будут применены не сразу.
Нагрузку он выдержит, но насколько это корректно.
Но на этапе проектирования хотелось бы избавится от подобных проблем.

mayton,

Хорошо, спасибо за совет.
22 фев 19, 16:43    [21817477]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
OoCc
Member

Откуда: с Кавказа
Сообщений: 1776
spider13
3) Каждый раз обращаться к авторизационному сервису, что ни есть хорошо при большом кол-ве запросов. Например отрисовка главного экрана приложения это обращение к 8 сервисам + взаимодейсвие между собой, и того на каждое соответствие нужно делать запрос.

Не проблема. WS-Policy и WS-PolicyAttachment хранятся как файлы. каждый раз микросервис при попытке загрузки получит ответ 304 Not Modified.
22 фев 19, 16:59    [21817497]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
Dima T
Member

Откуда:
Сообщений: 13634
spider13
Кеш на стороне сервиса не совсем хорошо, так как нужен expiration, т.е. при изменении прав они будут применены не сразу.

Можешь использовать классику: на стороне авторизационного сервиса задействовать memcached, в случае изменения прав пользователя - удалять его из кэша.
Так снизишь нагрузку на БД, но количество запросов не уменьшишь. Если это критично - вводи адекватный expiration, которого хватит хотя бы на отрисовку одной формы.

А права все равно будут применены не сразу, для передачи команды на изменение прав и само изменение потребуется 0.01-0.1 сек., поэтому мгновенная реакция невозможна, как следствие можно безболезненно чуть растянуть период, применив кэширование на 1-2 секунды, как было предложено.
22 фев 19, 17:02    [21817504]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
spider13
Member

Откуда: https://spider13.net/
Сообщений: 960
Dima T
spider13
Кеш на стороне сервиса не совсем хорошо, так как нужен expiration, т.е. при изменении прав они будут применены не сразу.

Можешь использовать классику: на стороне авторизационного сервиса задействовать memcached, в случае изменения прав пользователя - удалять его из кэша.
Так снизишь нагрузку на БД, но количество запросов не уменьшишь. Если это критично - вводи адекватный expiration, которого хватит хотя бы на отрисовку одной формы.

А права все равно будут применены не сразу, для передачи команды на изменение прав и само изменение потребуется 0.01-0.1 сек., поэтому мгновенная реакция невозможна, как следствие можно безболезненно чуть растянуть период, применив кэширование на 1-2 секунды, как было предложено.


Думал о таком варианте, спасибо.
Видимо сколько людей, столько и решений будет.

Все таки решил остановится на варианте промежуточного сервиса между nignx и микросервисами, который будет разворачивать
22 фев 19, 17:07    [21817508]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
alex55555
Member

Откуда:
Сообщений: 2095
spider13
а зачем тебе микросервисы?


Начинается...

Твой геморой с выбором решения (особенно желание во что бы то ни стало иметь кучу БД) показывает, начинаются проблемы из-за незнания ответа на поставленный вопрос.

Дробить по тупому не надо. Надо вменяемо проектировать на монолитном уровне, а потом, если реально возникнет потребность (которую ты ни разу пока не увидел, не понял и не осознал), вменяемое проектирование позволит безболезненно выделить взаимодействующие через декларативную обёртку сервисы.

Хотя для поощрения маразма тех, кто это всё придумал, я бы предложил делать по БД на каждую таблицу. Типа БД с таблицей "Справочник стран". А взаимодействие организовывать через сервис объединения данных, которому на вход пойдёт супер-мега-новый язык запросов, затем мега-парсер всё поймёт, оптимизирует, составит наилучший план обзвона всех БД, сджойнит результаты и отдаст ещё одному супер сервису - сервису отдач результата. И на каждом шаге внутри процесса, конечно же, нужна авторизация! Без неё никак, хакеры сегодня злые, потому что.
23 фев 19, 10:58    [21817767]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26469
alex55555
spider13
пропущено...


Начинается...

Твой геморой с выбором решения (особенно желание во что бы то ни стало иметь кучу БД) показывает, начинаются проблемы из-за незнания ответа на поставленный вопрос.

Дробить по тупому не надо. Надо вменяемо проектировать на монолитном уровне, а потом, если реально возникнет потребность (которую ты ни разу пока не увидел, не понял и не осознал), вменяемое проектирование позволит безболезненно выделить взаимодействующие через декларативную обёртку сервисы.

Хотя для поощрения маразма тех, кто это всё придумал, я бы предложил делать по БД на каждую таблицу. Типа БД с таблицей "Справочник стран". А взаимодействие организовывать через сервис объединения данных, которому на вход пойдёт супер-мега-новый язык запросов, затем мега-парсер всё поймёт, оптимизирует, составит наилучший план обзвона всех БД, сджойнит результаты и отдаст ещё одному супер сервису - сервису отдач результата. И на каждом шаге внутри процесса, конечно же, нужна авторизация! Без неё никак, хакеры сегодня злые, потому что.

Это же GraphQL Schema Stitching Картинка с другого сайта.
23 фев 19, 11:48    [21817777]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
kolobok0
Member

Откуда:
Сообщений: 1937
spider13
...Подскажите, как решить...


на мой взгляд есть два варианта:
1) либо идёт каждый раз запрос прав (когда мы знаем глагол выполнения и агентов)
2) зная глагол выполнения и агентов - обогащать данные запроса необходимой секьюрностью(пересечение агентов взаимодействия и самого глагола).

С точки зрения проблемы распространения прав на всю систему - думаю этим можно пренебречь, тем более если источником изменений является человек.
Или по другому - при изменение прав, администратор, полагается на изменение прав(как факта), а не на дробления текущего потока выполнения на две кучки - до и после правки.

(круглый)
23 фев 19, 13:32    [21817801]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
hVostt
Member

Откуда:
Сообщений: 15320
spider13
1) Записать их в JWT токен, но при обновлении прав они применяется только после выдачи нового токена, что ни есть хорошо.


Это как раз очень и очень хорошо.

И я не понимаю, как вообще можно относится к этому иначе. Даже если права не передаются в токене, сам факт авторизации -- это точка входа, пункт контроля, на котором пользователю выдаются его роли, полномочия, и т.д. и т.п. Нельзя, нельзя, менять их "на лету".

spider13
2) Общая БД, что не соответствует самой архитектуре микросервисов, да и есть сделать их как можно автономнее.


Сервис авторизации и есть тот самый "БД". Ходите в него за полным набором прав, если не хотите пихать их в токен, чтобы он не разбухал.


spider13
3) Каждый раз обращаться к авторизационному сервису, что ни есть хорошо при большом кол-ве запросов. Например отрисовка главного экрана приложения это обращение к 8 сервисам + взаимодейсвие между собой, и того на каждое соответствие нужно делать запрос.


Не каждый раз, а во время этапа авторизации. Один раз. Потом, кешируете. Ищите компромисс, однозначной пилюли для вас нет и не будет.
24 фев 19, 23:32    [21818391]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
Lessyp
Member

Откуда:
Сообщений: 122
spider13
3) Каждый раз обращаться к авторизационному сервису, что ни есть хорошо при большом кол-ве запросов. Например отрисовка главного экрана приложения это обращение к 8 сервисам + взаимодейсвие между собой, и того на каждое соответствие нужно делать запрос.

вообще-то микросервисы в любом случае будут обращатся к авторизационному сервису т.к. именно там лежат public keys для проверки подписи токена
26 фев 19, 03:50    [21819280]     Ответить | Цитировать Сообщить модератору
 Re: Авторизация и права в микросервисах  [new]
MirnyiAtom
Member

Откуда:
Сообщений: 29
spider13
1) Записать их в JWT токен, но при обновлении прав они применяется только после выдачи нового токена, что ни есть хорошо.

И каждый раз перед применение проверять токен на валидность
27 фев 19, 09:42    [21820206]     Ответить | Цитировать Сообщить модератору
Все форумы / Программирование Ответить