Skip to main content.

#rbac capability

he #rbac capability intends to provide the base operations for role-based access control. It defines a new "rbac" operation that allows a Netconf manager to activate and deactivate roles in his Netconf session. Activating a role allows to be granted some privileges. The access control policy is stored in the rbac.xml file.

Activating a role

To activate some roles, an "activate" sub-operation must be sent to the agent. It contains a set of roles that the manager wants to activate. In the example, the manager is going to activate the two roles "netAdmin" and "sysAdmin". It is up to the agent to decide if this activation is allowed or not.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rbac>
    <activate>
      <roles>
        <role>netAdmin </role>
        <role>sysAdmin </role>
      </roles>
    </activate>
  </rbac>
</rpc>

Deactivating a role

To deactivate some roles, a "deactivate" sub-operation must be sent to the agent. It contains a set of roles that the manager wants to deactivate. In the example, the manager is going to deactivate the role "sysAdmin". It is up to the agent to decide if this deactivation is allowed or not.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rbac>
    <deactivate>
      <roles>
        <role>sysAdmin </role>
      </roles>
    </deactivate>
  </rbac>
</rpc>

Appendix: Implementation specific information

YencaP stores a RBAC policy in the rbac.xml file. This policy defines:

Example: if a manager has "read" permission on //interface[name='eth0'], she will be allowed to read the whole subtree of all the selected nodes, plus their parents but without the children of their parents.