Стас, тебе для чего все это? собираешься делать PEP и PIP, или вообще все? оно вообще не особо распространено ввиду сложности из-за гибкости (ну плюс в XACML не особо-то и удобный xml), вот есть такие ссылки по теме:
https://en.wikipedia.org/wiki/XACML
https://habr.com/ru/company/custis/blog/258861/
https://github.com/CUSTIS-public/EasyABAC
https://github.com/authzforce/core

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

С таким рассказом шансов на реализацию у тебя крайне мало...

вот есть схема взаимодействия компонент:



на этой схеме:
- PEP - это то, что защищает какой-то ресурс/метод и пр., т.е. в приложении в большинстве случаев - это какой-то сервис, через/перед который производятся обращения к данным, он кидает запрос в PDP и оттуда получает в первом приближении ответ да/нет/неприменимо
- PDP - в общем случае оно может жить даже не в приложении, а где-то во вне, делает такое: обогащает запрос, пришедший от PEP, данными (т.е. обращается каким-то образом к PIP), если нужно, прогоняет его через реестр политик, в результате чего формируется ответ для PEP
- PAP - оно всю эту историю администрирует

с большой долей вероятности тебе ABAC не нужен, от слова совсем, потому что цели у него отличаются от "шарить ресурсы по ролям", основная цель у него - получение единой точки управления ИБ в инфраструктуре предприятия, и скорее всего тебе нужно в каком-нить @PreAuthorize "расширить" евойные возможности как-то так:
- можно сделать свой PermissionEvaluator и трактовать hasPermission() так как тебе хочется
- можно расширить SecurityExpressionRoot в DefaultMethodSecurityExpressionHandler#createSecurityExpressionRoot и реализовать свои собственные выражения

ты слово "атрибут" неправильно понимаешь: в ABAC "атрибут" - это нечто, существующее в рамках контекста, используемого для принятия решения, и к бизнес-логике он имеет отношение постольку-поскольку.