Я хочу обеспечить контроль доступа на уровне API-интерфейса Orion Context Broker NGSI, чтобы гарантировать реальную изоляцию данных. Я хочу убедиться, что арендатор может запрашивать / обновлять только свои контексты, а НЕ контексты другого арендатора.
Для этого я начал ставить перед собой экземпляр Wilma PEP Proxy. контекстного брокера Orion. Затем я настроил свой собственный экземпляр GE keyrock Identity Manager на основе официального образа докера IdM Keyrock. и мой собственный PDP GE для авторизации на основе официального образа докера AuthzForce.
После нескольких дней конфигураций и многих попыток, наконец, я смог заставить эти три универсальных активатора безопасности работать нормально, аутентифицируя и авторизуя запросы для API Orion Context Broker NGSI с использованием прокси-сервера PEP уровня 2.
Однако уровня 2 авторизации недостаточно, чтобы гарантировать то, что я хочу, потому что информация об услуге (клиент) и вспомогательной службе (путь к приложению) содержится в заголовках запроса. В частности, в заголовках Fiware-Service и Fiware-ServicePath. Для создания политик авторизации на основе заголовков вам необходимо использовать уровень 3: авторизация XACML.
Проблема в том, что я покопался в официальной документации Fiware и не смог найти ни одного примера политики XACML. Помимо официальной документации Wilma PEP Proxy (см. здесь) говорит, что вам, возможно, придется изменить исходный код PEP Proxy, чтобы получить этот уровень авторизации.
Поскольку этот случай предназначен для проверки дополнительных параметров запроса, таких как тело или настраиваемые заголовки, это зависит от конкретного варианта использования. Таким образом, программист должен изменить исходный код прокси-сервера PEP, чтобы включить в него определенные требования.
Возможно ли это?
Действительно ли мне нужно изменять исходный код прокси-сервера PEP, чтобы добиться чего-то столь же простого, как если бы арендатор мог получить доступ только к своим данным?
