Как реализовать ACL в системе на основе ElasticSearch?

Question

У меня есть система (RESTful), использующая NodeJS и Elasticsearch, которая реализует политику авторизации RBAC.Авторизация RBAC работает с сервером авторизации перед другими API, тестирующими каждый запрос на соответствие маршрутам, авторизованным для ролей пользователя (используя маркер носителя для аутентификации пользователя).

Мне нравится этот дизайн, потому что другие API не нужнызнать об услуге авторизации / аутентификации.И это очень, очень, очень быстро, потому что он использует политику кэширования в памяти, вместо этого отправляя запрос Elasticsearch каждый раз, когда получает новый запрос для проверки аутентификации.

Но теперь мне нужно реализовать ACL, чтобы обеспечитьболее детальный контроль авторизации.С точки зрения REST политика будет применяться на уровне ресурсов.Пример: «POST: / user / 123» авторизован только для пользователя A.

Я провел опрос с клиентами, и 85% будут использовать только политику allow ACL,по умолчанию элемент управления ACL будет отрицать все.Итак, теперь у меня есть вся информация для разработки этого элемента управления.Но я не вижу лучшего способа реализовать это.

Моя первая мысль была:

1. Самым важным качеством системы является масштабируемость;

2. Хорошо, это невозможно сделать в кеше памяти, я провел несколько симуляций с 100 000 пользователей и 1 миллионом ресурсов (что может быть реальным сценарием), и объем памяти ОГРОМ, этофункция будет иметь высокую стоимость при кэшировании:

3. В этом случае служба аутентификации не может обрабатывать ACL, поскольку она не может фильтровать результаты поиска.Служба аутентификации не перехватывает результаты, только проверяет заголовки и маршруты по ролям;

4. Итак, со всеми этими моментами, что если в каждом документе в Elasticsearch у меня было новое поле с именем "acl_allow_method_user ", который является массивом метода + идентификатора пользователя, уполномоченного использовать этот ресурс?В итоге получится что-то вроде этого:

"acl_allow_method_user":["POST:123434"]

Мне также придется создать общий пакет, который будет использоваться всеми API для проверки этой политики накаждое взаимодействие с Elasticsearch, но я не вижу никаких проблем с этим.

1. Кто-нибудь с опытом работы с ACL, это хороший дизайн?

2. Elasticsearch имеет ограничение на размер полей массива?

3. Как насчет производительности?Будет ли иметь влияние с этим подходом?

Answer 1

Для тех, кто сталкивается с той же проблемой, вот вывод, который мы делаем по этому случаю: будучи ACL-списками в микросервисах, REST-гранулирование с точки зрения ресурсов представляет собой трудности, аналогичные многопрофильной системе.

Ониявляются бизнес-логикой, и каждый сервис знает, «как» кто-то владеет ресурсом (и каковы возможные привилегии).Стандартизация способа хранения данных этих правил противоречит точному знанию логики каждой службы.

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

Пример без частной изоляции API ACL:

1. У нас есть 3 службы: «S (A)», которая отвечает за контроль пользователей и привилегий, «S (B)» и «S(C) », которые выполняют любую обычную задачу.

2. Приложение внешнего интерфейса должно понимать конечную точку S (A), S (B) и S (C) и делать отдельные запросыдля управления политиками ACL каждой службы.

Пример с частной изоляцией API и источником событий:

1. Присутствуют те же микросервисы.

2. Приложение внешнего интерфейса делает запрос к S (A), применяя некоторую политику ACL к S (B) и S (C).

3. S (А) записывает запрос на изменение политики и запускает событие в брокере, уведомляяИзменение политики.

4. S (B) и S (C) фиксируют событие и применяют политики в их логике.

5. S (B) и S (C) публикуют результаты реализации политики (предоставление или отзыв).

6. S (A) фиксирует событие результата применения политик и записывает этот результат.

Я выберу ответ от @alecswan как правильный, поскольку он был «отправной точкой», чтобы прийти к такому выводу.

Спасибо также @xeye, который предупредил нас очасть бизнес-логики.

Answer 2

Я бы предложил иметь отдельный индекс Elasticsearch для списков ACL, который должен быть намного меньше, чем индекс основного документа.Это позволит вам соответствующим образом настроить параметры индекса ACL, например, (1) с количеством сегментов, меньшим, чем индекс основного документа, (2) auto_expand_replicas, установленным в 0-all, в случае, если вы хотите использовать запрос условий (пример:загрузить все документы, принадлежащие пользователю) и (3) применять различные политики хранения / GDPR.

Индекс ACL может содержать документ для каждого правила ACL, например, userId = 1, docId = 123, opType = POST.Обратите внимание, что этот подход позволит вам определять правила ACL для других типов участников и ресурсов в будущем.Более того, это может поддерживать списки ACL, которые могут динамически сопоставлять новые документы, например, userId = 1, opType = POST, pattern = "*" позволит пользователю с userId = 1 публиковать любой документ, фактически являясь системным администратором.Отключение ACL от документов / пользователей позволит вам обновлять ACL без необходимости обновлять соответствующие документы, что будет работать лучше в Elasticsearch, который не выполняет обновление на месте, а вместо этого удаляет и заново создает документ.Более того, вы сможете заменить (PUT) весь документ, не беспокоясь о сохранении связанных ACL.Однако может потребоваться очистить списки ACL при удалении документов или пользователей, что можно сделать во время удаления или как отдельный запланированный процесс очистки.

Теперь, когда ACL отделены от самих документов, они могуткэшироваться в memcached или кластере Redis, не требуя слишком много памяти.В типичной системе OLTP в любой момент времени активен только небольшой набор пользователей, поэтому вы можете соответствующим образом настроить кэш LRU для увеличения частоты обращений.Трудно дать дополнительные рекомендации, не зная, какие шаблоны доступа характерны для вашей системы.

Последнее, на что следует обратить внимание, это , что генерирует ACL.Если некоторые ACL генерируются автоматически, например, на основе некоторого шаблона, то, возможно, вы могли бы использовать этот шаблон в своей системе, чтобы избежать наличия правила ACL для пользователя на документ.Например, если некоторые ACL генерируются из службы каталогов, вы можете кэшировать (и периодически обновлять) правила LDAP в вашей системе управления ACL.