Похоже, вам нужны два уровня внутреннего API, один из которых доступен для плагинов, а другой нет.
Лучший способ включить это - использовать OSGi (или Spring Modules). Это позволяет вам явно указать, к каким пакетам и классам могут обращаться другие модули (например, модули REST и модули плагинов). Это будет уровень вашего нового внутреннего API, и вы будете использовать Spring Security для дальнейшего выборочного ограничения доступа. Внутренние пакеты и классы будут содержать методы, выполняющие все низкоуровневые операции (например, удаление сущностей), и вы не сможете вызывать их напрямую. Некоторые из представленных API просто дублируют внутренний API с проверкой безопасности, но это будет нормально.
Проблема с лучшим способом состоит в том, что Spring Modules кажутся мне все еще слишком незрелыми, чтобы их можно было использовать в новом проекте веб-приложения. Я бы ни за что не захотел вставить это в старый проект.
Вероятно, вы могли бы добиться чего-то подобного, используя Spring Security и AspectJ, но мне кажется, что снижение производительности было бы непомерно высоким.
Одним из решений, которое было бы неплохо, если бы вы могли реструктурировать свою систему, было бы отключение задач, требующих повышения безопасности, или, наоборот, их асинхронность. Используя Quartz и / или Apache Camel (или соответствующий ESB), вы можете заставить метод «удалить мою учетную запись» создать автономную задачу, которая в будущем может быть выполнена как элементарная единица работы с привилегиями администратора. Это означает, что вы можете безошибочно выполнять проверки безопасности для пользователя, запрашивающего удаление учетной записи, в совершенно отдельном потоке, где фактически происходит удаление. Это позволит сделать веб-поток более отзывчивым, хотя вы все равно захотите сделать что-то немедленно, чтобы сохранить иллюзию того, что запрошенное действие было выполнено.