Andy Bierman a écrit :
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 trafficwrite: 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.
I don't really agree with this. When you define an access control model, you have to define permissions as a (action, resources) combination set. I think it is not possible to define permissions without a way of addressing data (XML-based or not). The ACM is usually strongly dependant on the data model. I don't understand what kind of access control policy you can specify if you don't consider the data but only the RPC ? Can you please give an example ?
Also a clear distinction between Access Control Model (which specifies who can do what), and supported operations (this data is writable or readable or both, ...) must be done. These are totally different concepts and sometimes I get confused when reading the messages.
IMO, a (read, write) based model is sufficient for access control. While "read" implicitely includes get, get-config, "write" implicitely includes edit-config (and its sub-operations), copy-config (write on the root node) and delete-config (write on the root node). If you define access control by RPC, you will need later to redefine access control on data: and that will be a two-levels access control which is hard to maintain and not necessary.
I think the distinction between create and write is not necessary. For example, in a table, you can give create access by allowing write access on the table. You can give update access by giving access to some particular entries in the table.
Regards, Vincent
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 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>
begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard