Единый вход - Лучшая практика - PullRequest
4 голосов
/ 03 июня 2010

Мне нужно создать масштабируемый механизм единой регистрации для нескольких сайтов. Сценарий:

  • Центральное веб-приложение для регистрации / управления учетной записью (сервер в Европе)
  • Несколько веб-приложений, которым требуется аутентификация по моей базе данных пользователей (серверы в США / Европе / Тихоокеанском регионе)

Я использую MySQL в качестве базы данных. Варианты, которые я предложил, это либо репликация базы данных пользователей на все серверы (защита данных?), Либо разрешение серверам напрямую подключаться к моему экземпляру MySQL путем явного разрешения подключений со своих IP-адресов в my.cnf (высокая нагрузка - одна точка отказа ?).

Каков наилучший способ обеспечить масштабируемый единый вход с низкой задержкой для всех веб-приложений? С точки зрения безопасности данных было бы хорошей идеей реплицировать базу данных пользователей во всех веб-приложениях?

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

Ответы [ 2 ]

3 голосов
/ 03 ноября 2010

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

Вам следует рассмотреть следующие вопросы (возможно, больше):

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

Методы, которые могут быть полезны:

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

0 голосов
/ 12 марта 2018

Вы должны пойти на Oauth2 или SAML.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...