Система авторизации и аутентификации для микросервисов и потребителей

Мы планируем преобразовать систему нашей компании в систему на основе микросервисов. Эти микро-сервисы будут использоваться нашими внутренними приложениями компании и сторонними партнерами, если это необходимо. Один для бронирования, один для продуктов и т. Д.

Мы не уверены, как справляться с ролями и областями применения. Идея состоит в том, чтобы создать 3 основные роли пользователя, такие как «Администраторы», «Агенты» и «Конечные пользователи», и позволить приложениям-пользователям настраивать области при необходимости.

• Администраторы могут создавать, обновлять, читать и удалять все ресурсы по умолчанию (для своей компании).
• Агенты могут создавать, обновлять и читать данные для своей компании.
• Конечные пользователи могут создавать, обновлять, удалять и читать данные, но не могут получать доступ к тем же конечным точкам, что и агенты или администраторы. Они также смогут создавать или изменять данные, но не на том же уровне, что агенты или администраторы. Например, конечные пользователи могут обновить или прочитать информацию своей учетной записи, так же, как агент сможет сделать это для них, но они не могут видеть или обновлять заметки администратора.

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

Рекомендуется ли обрабатывать это в нашей внутренней безопасности и разрешать им записывать эти данные в нашу базу данных или разрешать клиентам обрабатывать их внутренне, запрашивая токен с меньшей областью действия, и разрешать им писать, какой агент будет иметь какую область в своей базе данных ? Таким образом, мы должны отслеживать только области действия токенов.

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

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

Является ли эта делегация хорошим подходом?

Аутентификация и авторизация всегда хорошие темы

Я постараюсь объяснить вам, как мы работаем с разрешениями в текущей мультитенантной службе, над которой я работаю. Аутентификация и авторизация основаны на токене с использованием открытого стандарта JSON Web Token. Служба предоставляет REST API, к которому может обращаться любой клиент (веб, мобильные и настольные приложения). Когда пользователь успешно аутентифицирован, сервис предоставляет токен доступа, который должен отправляться при каждом запросе к серверу.

Итак, позвольте мне представить некоторые концепции, которые мы используем, основываясь на том, как мы воспринимаем и обрабатываем данные в серверном приложении.

Ресурс . Это любой элемент или группа данных, к которым клиент может получить доступ через службу. Всем ресурсам, которыми мы хотим управлять, мы присваиваем одно имя. Например, имея следующие правила конечной точки, мы можем назвать их следующим образом:

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на 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"
}

С помощью этого метода вы можете точно настроить доступ любой учетной записи пользователя к вашему сервису. И самое главное, вам не нужно создавать различные предопределенные и статические роли, такие как Admin, Agents и End-Users, как вы указали в своем вопросе. Супер Пользователь будет пользователь , который владеет roleсо всеми resourcesи actionsслужбы , возложенные на него.

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

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

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

Поскольку все вызывающие абоненты должны предоставить вашим микросервисам доказательства того, что они были аутентифицированы, вы также можете привязать разрешения к этой аутентификации. Если вы предоставите возможность привязать пользователя к произвольной группе доступа (или к группам, если вы хотите получить фантазию, хотя сложность добавления разрешений к вычитанию здесь сложнее), ваши клиенты будут получать меньше вопросов о том, почему пользователь х смог выполнить нежелательную операцию. В любом случае кто-то должен выполнить проверку списка доступа для каждой услуги, так что это может быть и вы. Это то, что очень легко закодировать в начале всех сервисов (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) Что вы можете сделать это и сами отслеживать группы пользователей. Это правда, что у вас должен быть менеджер группы разрешений, и вы можете использовать его в пользовательском интерфейсе управления пользователями (используйте существующую / создайте новую группу для полномочий пользователей). Определенно перечислите пользователей, привязанных к группе, когда вы редактируете определение, чтобы избежать путаницы. , Но это не тяжелая работа. Просто получите метаданные для всех сервисов и свяжите поиск соответствия между группой и сервисом с обработкой токена аутентификации.

Хорошо, так что есть довольно много деталей, но каждый из ваших клиентов, которым нужна эта функциональность, должен был бы в любом случае закодировать это, и если вы поддерживаете трехуровневые пользовательские разрешения, вы можете просто расширить его до уровня доступа для каждого пользователя. групп. Вероятно, логическое пересечение между разрешениями базовой группы и разрешениями, специфичными для пользователя, будет правильным объединением, но если вы хотите иметь возможность добавлять и убирать базовые разрешения для прав администратора, агента, базового пользователя, вам нужно сделать Обычный флаг трех состояний в группах разрешений: Добавить разрешение, Запретить разрешение, Разрешение по умолчанию и соответствующим образом объединить разрешения.

(Как примечание, все это должно происходить с чем-то вроде SSL или даже с двусторонним SSL, если вы беспокоитесь о безопасности обоих концов диалога. Если вы «утечете» эти токены злоумышленнику, он как будто Я взломал пароль.)

Я считаю, что у вас есть два варианта здесь.

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

• Если ваши клиенты разрабатывают свои собственные приложения, им следует представить свои собственные промежуточные API. Который подключается к вашему как администратор, но проверяет входящий запрос на соответствие их собственным требованиям авторизации перед вызовом ваших служб

Соображение безопасности

Если я хорошо понимаю ваш дизайн, вы намереваетесь делегировать некоторые механизмы управления доступом к ресурсам на стороне клиента, то есть приложение-потребитель сокращает количество элементов, которые может видеть пользователь. Ваше предположение:

Микроуслуги и их система авторизации не должны беспокоиться о потребностях клиентов, потому что они являются только потребителями, а не частью системы.

Я вижу здесь две серьезные проблемы для серьезного бизнеса:

• Что если какой-то мошенник (например, на одном из заводов вашего партнера) обратный инжиниринг клиентского приложения и узнает об API, обойти ограничения, которые его компания наложила на клиента, и использовать эту информацию, чтобы нанести вред вашей компании? Ваша компания будет требовать возмещения убытков, но компания-партнер будет утверждать, что вы не предоставили средства для защиты ваших данных достаточно хорошо.
• Как правило, это только вопрос времени, когда конфиденциальные данные используются не по назначению (или аудит обнаружит риск), и ваше руководство в конечном итоге потребует более жесткого контроля над этими данными.

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

Если вы занимаетесь своим текущим положением, проконсультируйтесь по крайней мере с вашим сотрудником по информационной безопасности.

Как это реализовать

У вас есть трюк:

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

Хорошо, вы намереваетесь использовать некоторые общие токены, выбранные клиентом. Опять слабость в моих глазах, потому что некоторые клиенты могут быть вне вашего контроля.

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

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

Здесь тоже есть короткий ответ. Вы должны реализовать все основные функции, которые вы хотите предложить своим «клиентам» самостоятельно. Кажется проблематичным, чтобы клиенты добавляли такое фундаментальное поведение, как права пользователя, поскольку вы уже выполняете аутентификацию пользователя; если вы предоставите клиенту возможность его реализовать, вы можете в конечном итоге «поддерживать» несколько реализаций одного и того же кода разрешений. Даже если вы не «владеете им», в их коде будут ошибки, и вы хотите, чтобы ваши клиенты имели ожидаемые функции, в разумных пределах, поэтому вы поддерживаете решение проблем, которые возникают у клиента. Поддержка нескольких кодовых баз - это не весело.