Balazs Lengyel wrote:
Hello,
You are right, we need access control.
For this reason each action defined in the data model should be
defined as read/write/disturb-traffic.
read: it only reads configuration and state data and doesn't effect
the traffic
write: it writes configuration data, but does not disturb the traffic
disturb-traffic: means it can do anything.
IMO, a clean access control model for NETCONF need to recognize
the RPC model and the configuration datastore architecture.
First, there is the RPC method, defined by a QName.
The user must have access to invoke the RPC method.
Completely independent of that is the data access control model
applied to all configuration datastores. The NETCONF operations
are create, delete, merge, and replace. For access control purposes,
merge and replace operations are treated as a 'create' if the target
data instance does not exist.
The granularity could be a coarse as read/write, but that would
totally defeat the purpose of create and delete operations in
the edit-config method. An access control that matches the
capabilities of the protocol needs to include read/write/create+delete
as the 3 levels of data access (4 if you count 'none').
It makes no sense to have an 'exec' or 'disturb-traffic' access
control classification in the data space. Either the user can
invoke the RPC method or not. Remember, it is the PROTOCOL that
needs an access control model, not blobs of XML. IMO, focusing the ACM
on the XML is the wrong approach.
One can debate that these are the good categories for access control.
Still the basic statement is that for each action defined in the data
model you need to specify it's access properties in the data model as
well.
Balazs
Andy Bierman wrote:
Your access control model should be more robust than
simply allowing user X to do anything called <action>.
I don't see what benefit an intermediate SW component
can realize if an extra generic container is added to <rpc>.
Andy