[MDSAL-839] Integrate java.security.Principal into request APIs

Tue, 9 Jan 2024 09:10:09 +0000

We completely lack security awareness in our APIs. We should do better.

Our current APIs completely ignore the question of who is making the request, leaving validation to upper layers, exposed outside requests.

This makes for quite some trouble for implementations. Let us say our AAA project wants to expose an requestor-sensitive DataBroker (performing, for example netconf-acm-based request filtering) and our NETCONF project wants to use this DataBroker, off-loading the AAA decisions.

restconf-nb does have the access to javax.ws.rs.core.SecurityContext, which exposes the requesting user as a java.security.Principal, but it has no way of communicating it to the DataBroker instance it is using.

From solution space, we want to cause minimum churn to downstream users, while extending introducing this awareness.

I think we want to introduce intermediate DataBrokerFactory, RpcConsumerRegistryFactory, ActionServiceFactory and others as the baseline interfaces. Users would inject these through OSGi DS and then either use them directly (RESTCONF) or provide an explicit application-specific Principal to get DataBroker, RpcConsumerRegistry or ActionService.

For such application-level Principals, each application would describe its access model – i.e. which data it reads, which data it writes, which RPCs it implements and which notifications it produces/consumes – and get an DataBroker (or other interface) based on that description.

Proposed factories would then produce DataBroker et al. interfaces which check each access to conform with the specification, perhaps somehow exposing a java.security.Permission to the actual invocation.

OpenDaylight JIRA

[MDSAL-839] Integrate java.security.Principal into request APIs