[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Access control [was: action RPC I-D]
Balazs Lengyel wrote:
I feel that we should be careful not to make access control to
complicated. While technically it is possible to design a good, fine
grained access control model, I fear the user (operator) will have
difficulties understanding it.
I see that read/write (and possibly disturb traffic) are three easy to
understand concepts that might be executed by different people in the
network operator's organization. On the other hand I don't see who would
be the operator who is allowed to modify a route(or a customer), but not
to create a new one.
I agree that operationally separating delete, replace, etc. is a useful
notion, but I don't see the need for the same with access control.
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)
If the granularity of the entire ACM is read or write, then how do
you identify (in the data model schema) which subtrees can be created
by any NMS? Also, how do you tell the agent that the user is allowed
to create specific child nodes of <interface>, but not an <interface>
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.