Re: [netconf] Identity of an OAM user behind ONAP or NMS

[Kent Watsen <[e-mail]>]

Hi Balazs,

> We have systems where the Netconf client is actually a bigger management system like ONAP or a Network Management system (NMS). These systems have their own user management and access control with potentially many dozens of OAM users that can handle thousands of nodes. We do not want create and maintain these dozens of users in thousands of nodes. The idea is to have a single NMS user that has superuser rights and leave the access control to the NMS.

This is what I’ve seen mostly: assuming NMS is the master, all AAA happens there.


> However, this presents a problem: The Netconf server does not have the effective user identity who ordered the action in NMS.

At first I thought you were going to say this is an issue because the server can’t implement access control, but it seems it’s more to do with attributing the userid in the audit trail logs...


> Still it would be good to include this effective userId in the audit trail logs on the Netconf server.

Assuming the only goal is to correlate the server-generated audit logs, techniques I’ve seen used include:

1) temporal correlation:  i.e., assume the audit logs generated by a server in some window of time immediately after a configuration update are related to that update event, and hence attributed to the NMS user.  PROs: no device modification required.  CONs: assumes non-overlapping and somewhat infrequent updates.

2) opaque correlation: if the device supports either a) accepting an opaque value in the request or b) generating an UID that it  returns in the RPC-reply that, in other case, it outputs in downstream audit logs.  This value can be used by the NMS to correlate audit-logs to the NMS-update, from which the NMS-user can be determined.  PROs: deterministic.  CONs: requires device support.

3) use remote-auth protocols, mentioned by Jan Lindblad.   PROs: also supports out-of-band updates.  CONs: requires greater network infrastructure access from all the servers.


> IS there some standard way to send such a second effective-user-id to the Netconf server? Would there be interest for defining such a mechanism?

If solely interested in audit-logs generated when <intended> is updated, then it is effectively always a synchronous update. But from the opstate-reqs days, it would be good to know when an update is *applied* (see requirement 2B in draft-ietf-netmod-opstate-reqs-04 <https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04>).  Of course, this consideration is additionally complex in cases, e.g., when a line-card is plugged in.

Nonetheless, for cases where the device knows that the RPC will be processed asynchronously, it might be good to return in the RPC-reply a handle (UID) that can be used in subsequent requests and/or returned in audit-logs for offline correlation.  An I-D along these lines might be generally useful.


Kent // contributor