Мы планируем преобразовать систему нашей компании в систему на основе микросервисов. Эти микро-сервисы будут использоваться нашими внутренними приложениями компании и сторонними партнерами, если это необходимо. Один для бронирования, один для продуктов и т. Д.
Мы не уверены, как справляться с ролями и областями применения. Идея состоит в том, чтобы создать 3 основные роли пользователя, такие как «Администраторы», «Агенты» и «Конечные пользователи», и позволить приложениям-пользователям настраивать области при необходимости.
- Администраторы могут создавать, обновлять, читать и удалять все ресурсы по умолчанию (для своей компании).
- Агенты могут создавать, обновлять и читать данные для своей компании.
- Конечные пользователи могут создавать, обновлять, удалять и читать данные, но не могут получать доступ к тем же конечным точкам, что и агенты или администраторы. Они также смогут создавать или изменять данные, но не на том же уровне, что агенты или администраторы. Например, конечные пользователи могут обновить или прочитать информацию своей учетной записи, так же, как агент сможет сделать это для них, но они не могут видеть или обновлять заметки администратора.
Предположим, что агенты по умолчанию могут создавать, считывать и обновлять каждый ресурс для своей компании, и это их максимальная область действия, которую можно запросить для их токена / сеанса, но разработчики клиентского приложения (API-потребителя) решили, что один из их агентов может читать и создавать только определенные ресурсы.
Рекомендуется ли обрабатывать это в нашей внутренней безопасности и разрешать им записывать эти данные в нашу базу данных или разрешать клиентам обрабатывать их внутренне, запрашивая токен с меньшей областью действия, и разрешать им писать, какой агент будет иметь какую область в своей базе данных ? Таким образом, мы должны отслеживать только области действия токенов.
Недостатком этого является то, что нашей команде также потребуется создать отлаженные механизмы доступа во внутренних приложениях.
При таком подходе микросервисы и их система авторизации не должны беспокоиться о потребностях клиентов, потому что они являются только потребителями, а не частью системы (даже если некоторые из этих потребителей являются нашими собственными внутренними приложениями)?
Является ли эта делегация хорошим подходом?
payment:[read]
, так и у продавцаpayment: [create]
. Вы агрегируете разрешения в этом случае?(resource/action)
, вы должны объединить их. Если разрешения перекрываются, их необходимо объединить. Идея состоит в том, чтобы определить только ресурсы и действия, разрешенные в токене, оставив роли как абстракцию, используемую для предоставления клиентам менее сложного способа работы с авторизацией.user
свойство в своей полезной нагрузке. Я блокирую ресурс, принадлежащий пользователю, путем сопоставленияuser
заявки с URL-адресом. Например:/users/coyote/back-account
будет доступен только для токена сuser
утверждением, равнымcoyote
. Я надеюсь, что это поможет.Я думаю, что несмотря ни на что, вы захотите, чтобы ваши службы принимали токен аутентификации, предоставляемый службой аутентификации, которую вы пишете для проверки пользователей. Это самый простой / безопасный способ предотвратить неправильное использование ваших микросервисов. Кроме того, в целом, если вы хотите, чтобы клиент имел хороший опыт, вы должны самостоятельно реализовать критические функции и тщательно протестировать, чтобы убедиться, что предлагаемые вами функции хорошо реализованы.
Поскольку все вызывающие абоненты должны предоставить вашим микросервисам доказательства того, что они были аутентифицированы, вы также можете привязать разрешения к этой аутентификации. Если вы предоставите возможность привязать пользователя к произвольной группе доступа (или к группам, если вы хотите получить фантазию, хотя сложность добавления разрешений к вычитанию здесь сложнее), ваши клиенты будут получать меньше вопросов о том, почему пользователь х смог выполнить нежелательную операцию. В любом случае кто-то должен выполнить проверку списка доступа для каждой услуги, так что это может быть и вы. Это то, что очень легко закодировать в начале всех сервисов (
if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }
) Что вы можете сделать это и сами отслеживать группы пользователей. Это правда, что у вас должен быть менеджер группы разрешений, и вы можете использовать его в пользовательском интерфейсе управления пользователями (используйте существующую / создайте новую группу для полномочий пользователей). Определенно перечислите пользователей, привязанных к группе, когда вы редактируете определение, чтобы избежать путаницы. , Но это не тяжелая работа. Просто получите метаданные для всех сервисов и свяжите поиск соответствия между группой и сервисом с обработкой токена аутентификации.Хорошо, так что есть довольно много деталей, но каждый из ваших клиентов, которым нужна эта функциональность, должен был бы в любом случае закодировать это, и если вы поддерживаете трехуровневые пользовательские разрешения, вы можете просто расширить его до уровня доступа для каждого пользователя. групп. Вероятно, логическое пересечение между разрешениями базовой группы и разрешениями, специфичными для пользователя, будет правильным объединением, но если вы хотите иметь возможность добавлять и убирать базовые разрешения для прав администратора, агента, базового пользователя, вам нужно сделать Обычный флаг трех состояний в группах разрешений: Добавить разрешение, Запретить разрешение, Разрешение по умолчанию и соответствующим образом объединить разрешения.
(Как примечание, все это должно происходить с чем-то вроде SSL или даже с двусторонним SSL, если вы беспокоитесь о безопасности обоих концов диалога. Если вы «утечете» эти токены злоумышленнику, он как будто Я взломал пароль.)
источник
Я считаю, что у вас есть два варианта здесь.
Если вам просто необходим настраиваемый доступ к практически одному и тому же приложению, тогда службы должны проверить разрешения и предоставить вашим клиентам интерфейс, позволяющий им изменять разрешения, предоставляемые каждой роли. Это позволяет большинству пользователей использовать настройки ролей по умолчанию, которые «проблемные» клиенты могут настроить для ролей или создать новые в соответствии со своими потребностями.
Если ваши клиенты разрабатывают свои собственные приложения, им следует представить свои собственные промежуточные API. Который подключается к вашему как администратор, но проверяет входящий запрос на соответствие их собственным требованиям авторизации перед вызовом ваших служб
источник
Соображение безопасности
Если я хорошо понимаю ваш дизайн, вы намереваетесь делегировать некоторые механизмы управления доступом к ресурсам на стороне клиента, то есть приложение-потребитель сокращает количество элементов, которые может видеть пользователь. Ваше предположение:
Я вижу здесь две серьезные проблемы для серьезного бизнеса:
Вот почему я бы посоветовал предвидеть такие события и заботиться о запросах на авторизацию. Вы находитесь на ранней стадии реинжиниринга, и вам будет гораздо легче учесть это в вашей архитектуре (даже если вы не реализуете их все), чем позже.
Если вы занимаетесь своим текущим положением, проконсультируйтесь по крайней мере с вашим сотрудником по информационной безопасности.
Как это реализовать
У вас есть трюк:
Хорошо, вы намереваетесь использовать некоторые общие токены, выбранные клиентом. Опять слабость в моих глазах, потому что некоторые клиенты могут быть вне вашего контроля.
Я не знаю, используете ли вы уже JWT или какие-то другие методы. Но если вы используете JWT, у вас может быть токен идентификации, который несет личность пользователя (и даже второй токен, который надежно идентифицирует исходное приложение, которое может позволить вам различать уровень доверия между внутренними клиентами и внешними клиентами ).
Поскольку вы намереваетесь использовать микросервисную архитектуру, я хотел бы предложить различие между управлением пользователями и процессом аутентификации (который должен выполняться как выделенный сервис) и контролем доступа (который характерен для каждого микросервиса и должен обрабатываться локально каждым из них). Конечно, для простоты использования некоторые клиенты-администраторы должны предоставить исчерпывающий обзор нескольких служб.
источник
Здесь тоже есть короткий ответ. Вы должны реализовать все основные функции, которые вы хотите предложить своим «клиентам» самостоятельно. Кажется проблематичным, чтобы клиенты добавляли такое фундаментальное поведение, как права пользователя, поскольку вы уже выполняете аутентификацию пользователя; если вы предоставите клиенту возможность его реализовать, вы можете в конечном итоге «поддерживать» несколько реализаций одного и того же кода разрешений. Даже если вы не «владеете им», в их коде будут ошибки, и вы хотите, чтобы ваши клиенты имели ожидаемые функции, в разумных пределах, поэтому вы поддерживаете решение проблем, которые возникают у клиента. Поддержка нескольких кодовых баз - это не весело.
источник