Многопользовательский централизованный сервер аутентификации - PullRequest
Новая
       41

Многопользовательский централизованный сервер аутентификации

0 голосов
/ 29 сентября 2018

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

Обзор:

  • Пользователи могут быть связаны с одним или несколькими проектами
  • Пользователи имеют одинаковые учетные данные для всех проектов, с которыми они связаны
  • Использовать JSON Web Tokens - использовать полезную нагрузку для добавления пользовательских данных, субдомена (проекта) для маршрутизации,роль и т. д.
  • Субдомен не будет использоваться для входа в систему.Все пользователи будут входить на один и тот же сайт и будут перенаправлены на проект, с которым они связаны (или заданный список, если их несколько).SSO является необязательным.

Вопросы / неопределенности:

В: Должны ли токены аутентификации создаваться на сервере аутентификации или в каждом проекте?т.е.) У каждого пользователя есть один токен авторизации для всех проектов или один токен авторизации для каждого проекта?

В: Роли будут храниться в каждом приложении.Я хотел бы отправить роли вместе с токеном аутентификации в JWT.Должны ли эти данные избыточно храниться на сервере аутентификации?Другим другим способом будет доступ сервера аутентификации к базам данных проекта.Каков наилучший способ справиться с этим?У пользователей будут разные роли для каждого проекта.

В: Сервер аутентификации будет иметь основную информацию о пользователе (электронная почта / имя пользователя, пароль, имя / фамилия и т. Д.).Поскольку внешние ключи не могут использоваться между базами данных, я могу использовать прокси-сервер пользователя на основе имен пользователей для создания пользователя в каждом проекте.Нужно ли серверам приложений иметь доступ к токенам аутентификации, действующим?

Использование преимуществ уже существующего программного обеспечения:

  • Другой подход, который я задумалдолжен был использовать django-tenant-schemas, которая использует схемы Postgres, где каждый из моих проектов был бы схемой (в настоящее время использующей базы данных MYSQL).Имеет ли смысл воспользоваться этим?
  • Могу ли я воспользоваться услугой IdP для разгрузки части аутентификации?Легко ли это связать со слоем аутентификации Django?

1 Ответ

0 голосов
/ 29 сентября 2018

Ваш вопрос, кажется, множественный, поэтому я бы тоже разделил ответ:

О ПОЛЬЗОВАТЕЛЯХ

Поскольку ваши пользователи не являются частью вашей "модели мятежности"у вас есть два варианта:

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

Это означает, что ваша схема базы данных будет выглядеть примерно так: 

 root database (all common data here)
 project 1 database (with it's own user data or referencing root)
 project 2 database (with it's own user data or referencing root)

Теперь для токенов аутентификации

У вас есть те же опции, что и выше:

  1. Сохраните их в корневой базе данных и напишите свойсобственное промежуточное программное обеспечение.
  2. Копируйте их.

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

Поскольку ваш вариант использования довольно специфичен, вы можете столкнуться снекоторое сопротивление со стороны существующего программного обеспечения.Но создать собственное мультитенантное решение не так уж сложно, 1039 *

...