Повторное использование услуг в Cloud Foundry с программными и интерактивными конечными точками
Мне интересно, возможно ли реализовать службу, размещенную в Cloud Foundry, на которую могут подписаться другие приложения CF, со следующими требованиями и (более или менее) в рамках существующих средств CF...
Контекстом вопроса является преобразование существующего приложения на основе CF Java в повторно используемую службу, которая может быть развернута только один раз и повторно использована другими (не связанными между собой) приложениями, вместо того чтобы каждое приложение (или набор приложений) включало частный развернутый экземпляр сервис.
В двух словах, подписавшиеся приложения должны иметь возможность хранить свои данные в сервисе и интерактивные пользователи для доступа к этим данным. (Примером данных могут быть сообщения для конкретного пользователя, рабочие элементы и т. Д., Отправленные подписывающимися приложениями, и служба отвечает за их агрегирование для каждого пользователя и отображение вошедшему в систему пользователю сводных данных о целевых данных. в него.)
Таким образом, требования будут:
Приложения, размещенные на CF, должны иметь возможность динамически подписываться на сервис (и позже отказываться от него).
Подписные приложения могут совместно использовать или иметь разных провайдеров идентификации (IdP) и экземпляры UAA.
Служба имеет два вида конечных точек:
- конечные точки, предназначенные для вызовов app2service (REST и т. д.) приложениями-подписчиками
- конечные точки, предназначенные для интерактивного доступа пользователей, зарегистрированных в IdP приложений-подписчиков
Интерактивные конечные точки Сервиса (предпочтительно) защищены областями. Должна быть (предпочтительно) возможность для службы экспортировать свои определения области действия в UAA подписывающихся приложений (или, скорее, для подписывающихся приложений /UAA для импорта их во время проектирования, развертывания или подписки), а также для администратора данный UAA назначать определенные сервисом области соответствующим пользователям, зарегистрированным через эту комбинацию UAA/IdP (т. е. одну, связанную с подписывающимся приложением).
4.1. Как минимум, интерактивные конечные точки могут быть оставлены незащищенными областями, но они должны требовать и инициировать аутентификацию (например, имея "intercept-url access=isAuthenticated()" в своих дескрипторах безопасности Spring). Сервлет должен иметь возможность извлекать токен JWT и идентифицировать пользователя, выполняющего запрос.
- У службы должен быть способ связывания между пространствами имен идентификаторов пользователей и идентификаторами подписок.
Два разных контекста подписки, связанные с двумя разными IdP, могут иметь пользователя "Джон", но это два разных Джона.
Поэтому, когда пользователь Джон прибывает в интерактивную конечную точку службы, служба должна иметь возможность выяснить, на какой набор IdP/ подписки (и, следовательно, набор данных) сопоставляется этот Джон.
Или, наоборот, когда подписанное приложение выполняет вызов app2service, служба должна иметь возможность идентифицировать идентификатор подписки вызывающего абонента аутентифицированным способом, а затем выяснить, с каким IdP оно связано. В любом случае важно, чтобы механизм подписки предусматривал установление сопоставления между идентификатором подписки и IdP, используемым подписывающимся приложением; служба должна знать это отображение.
5.1. Не слишком уверен, как именно все должно работать, когда два разных экземпляра UAA указывают на один и тот же резервный IdP.
Возможно, UAA может представить свою идентификацию экземпляра, но может ли она быть представлена для представления (в сгенерированных токенах JWT) идентификатора резервного IdP, и может ли последний быть подписан?
Это что-то, что предоставляют существующие средства CF или что может быть легко реализовано поверх них?
Благодарю.