Проектирование сервисов SOA/аутентификация

Я новичок в SOA и поэтому экспериментирую.

В настоящее время самой большой проблемой для меня является аутентификация, мои текущие мысли об этом включают следующее:

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

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

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

  2. Служба аутентификации хранит всю информацию о сеансе в оперативной памяти и отвечает на запросы без обращения к БД.

  3. Служба аутентификации отправляет авторизованное сообщение на esb, esb пересылает это авторизованное сообщение каждой службе, и эти службы кэшируют его. Никаких дополнительных запросов к службе аутентификации не потребуется. Если пользователь выходит из системы или его роли меняются, другое сообщение будет отправлено и обработано всеми службами.

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

Второй по-прежнему очень прост в реализации, но нагрузка на службу аутентификации остается почти такой же.

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


person Community    schedule 18.08.2009    source источник


Ответы (2)


Лучший подход должен быть таким, если все сервисы внутренние,

  1. Служба проверки подлинности выдает маркер клиенту службы.
  2. Клиент службы включает токен в сообщение SOA, завернутое в WS-Security или что-то подобное.
  3. Служба должна проверить токен с помощью службы аутентификации перед предоставлением службы.

Что касается внешних служб, я предлагаю вам рассмотреть интегрированные решения, такие как SAML.

person ZZ Coder    schedule 18.08.2009
comment
Не могли бы вы ответить на stackoverflow.com/questions/9553267/ ? - person LCJ; 04.03.2012

Не выполняйте преждевременную оптимизацию. Ваш вариант – нет. 3, который, как вы признаете, будет сложнее реализовать, не нужен. Выберите вариант №. 2, если это то, что вы можете реализовать быстро. Вы можете профилировать позже и изменить его, но я готов поспорить, что у вас не будет «узкого места» при выборе варианта 2.

person Alex    schedule 18.08.2009
comment
Не могли бы вы ответить на stackoverflow.com/questions/9553267/ ? - person LCJ; 04.03.2012