[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Access control [was: action RPC I-D]

Juergen Schoenwaelder wrote:

On Thu, Nov 02, 2006 at 07:41:13AM -0800, Andy Bierman wrote:


There are 4 components to implementing an isAccessAllowed internal API:

  - maximum access that makes protocol sense
    - SNMP uses read-create to identify table rows that the NMS
      and agent can create, and read-write to identify scalars and
      table rows that only the agent can create.

  - access requested in the PDU

  - identity or the requester (e.g., user name, group name)

  - maximum access allowed for the requester (configured on the agent)


The maximum access that makes protocol sense is IMHO not an input to
isAccessAllowed - there is no runtime decision to make. The maximum
access that makes protocol sense is input for the tools that drive
your implementation; there simply is no write method to call for
read-only objects. In the SNMP processing, you return an error before
you ever get to the isAccessAllowed() function if I remember things
well.


The maxAccess check could also be part of validation phase at runtime.
The implementation aspects are not really important here.

In a real data model, there are going to be
 - nodes that should be there every time (e.g., <interfaces> container)
 - nodes that the agent is only allowed to create, but may not be present
 - nodes that both the agent and NMS are allowed to create
 - nodes that only the NMS will create (based on desired feature config)

Perhaps new <appInfo> mechanisms will be needed, totally unrelated
to the way SMIv2 handles this issue.

IMO, distinguishing between editing existing instances and creating
new instances is useful, but probably not important.




/js



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/>