Смешивание сервисно-ориентированной архитектуры безопасности и бизнес-логики

Question

У меня есть SOA, который активно использует одноразовые номера (то есть одноразовые одноразовые токены безопасности).

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

Проверка и генерация одноразового номера оперативно связаны с бизнес-логикой, поскольку оба они происходят в ответ на каждый запрос клиента. Однако я не хочу, чтобы они были связаны в коде. Как правильно разделить их в соответствии с принципами SOA? Не слишком ли много, чтобы разбить систему безопасности и бизнес-логику на две отдельные службы, одна из которых вызывает другую как часть каждого ответа на каждый клиентский запрос?

Answer 1

Да, имеет смысл разделять их.Но я не думаю, что они вообще должны быть осведомлены друг о друге (звоните друг другу напрямую).

Я расскажу о конкретном примере и технологии того, как реализовано нечто подобное.

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

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

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

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

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

Ниже приведена ссылка на ссылку перехватчика struts2 (это может прояснить идею лучше): http://struts.apache.org/2.2.1.1/docs/interceptors.html

Следующие две ссылкиоба перехватчика управляют токенами: http://struts.apache.org/2.2.1.1/docs/token-interceptor.html

http://struts.apache.org/2.2.1.1/docs/token-session-interceptor.html

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

Answer 2

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

Это было бы особенно верно, если у вас есть (или есть вероятность) другие услуги, которые будут полагаться на одноразовые номера.