Subject: [Netconf] nacm proposal

From: Martin Bjorklund <[email-masked]>
Date: Sun, 13 Mar 2011 22:04:29 +0100 (CET)

Hi,

Below is a proposal for some changes to NACM to make it easier to use,
that I will present in Prague.

It is common to think and configure role based access control in terms
of features or tasks.  A task/feature can be 'routing', 'system', or
'vpn-admin' etc.

There are two problems involved when such tasks are mapped to nacm. 

One problem is that it is difficult to understand which individual
rules in larger configurations belong together, because there is just
a single list with all rules (of a certain type).  This makes it more
difficult to maintain the rules.

The other problem is that a certain task might involve rules of
different types, thus the rules will be spread out in up to four
different lists (module-rule, rpc-rule, data-rule, and
notification-rule), which makes it even more difficult to understand
and maintain the rules.

The following proposal changes the structure of the rules a bit, in
order to make it easier to create, understand, and maintain access
control rules.  It does not change the underlying execution model of
rules; i.e. it is equivalent in expressive power to the current
document.

The idea is that we introduce named "rule-lists".  A rule-list is a
named collection of rules, and it can be shared among different
groups.  Instead of four different rules lists, there is just one,
where the different rule types are done with a choice.

Here's an example, using a YANG-like syntax for the content, instead
of XML:

  rule-list networking {

      allowed-group [ wheel admin ];

      rule allow-ietf-interface {
          module-name "ietf-interface";
          access-rights *;
	  action permit;
      }
      rule deny-reset {
          module-name "acme-ethernet-interface";
          rpc-name "reset-interface";
          access-rights [ execute ];
	  action deny;
      }
      rule allow-acme-ethernet {
          path "/if:interfaces/if:interface/acme:eth-config";
          access-rights [ read update notify ];
	  action permit;
      }
  }

Using this, a "task" can be represented as a rule-list, and a large
configuration can be broken down into manageable tasks.

Here's a compact representation of the rule-list:

   +--rw nacm
      +--rw rule-list [name]
         +--rw name             string
         +--rw allowed-group*   union
         +--rw rule [name]
            +--rw name                 string
            +--rw module-name?         union
            +--rw (rule-type)?
            |  +--:(rpc)
            |  |  +--rw rpc-name?            union
            |  +--:(notification)
            |  |  +--rw notification-name?   union
            |  +--:(path)
            |     +--rw path                 schema-instance-identifier
            +--rw access-rights        union
            +--rw action               nacm-action-type

And the YANG definition of the rule-list:

  container nacm {

    list rule-list {
      key "name";
      ordered-by user;

      description
        "A named list of access control rules.";

      leaf name {
        type string {
          length "1..255";
        }
        description
          "Arbitrary name assigned to this access control rule list.";
      }

      leaf-list allowed-group {
        type union {
          type nacm-matchall-string-type;
          type nacm-group-name-type;
        }
        min-elements 1;
        description
          "List of administrative groups which will be assigned the
           associated access rights for the content specified by the
           associated path.

           The string '*' indicates that all configured
           administrative groups apply to the entry.";
      }
      
      list rule {
        key "name";
        ordered-by user;

        description
          "Rules are processed in user-defined order until a match is
           found.  A rule matches if 'module-name' and 'rule-type'
           matches the request.  If a rule matches, the 'action' leaf
           determines if access is granted or not.";

        leaf name {
          type string {
            length "1..255";
          }
          description
            "Arbitrary name assigned to the access control rule.";
        }
        
        // match on these leafs...
        leaf module-name {
          type union {
            type nacm-matchall-string-type;
            type string;
          }
          default "*";
          description
            "This leaf matches if it has the value '*', or if the
             object being accessed is defined in the module with the
             specified module name.";
        }

        choice rule-type {
          description
            "The choice matches if all leafs present in the rule
             matches the request.  If no leafs are present, the
             choice matches the request.";
          case rpc {
            leaf rpc-name {
              type union {
                type nacm-matchall-string-type;
                type string;
              }
              description
                "This leaf matches if its value equals the requested
                 RPC operation name.";
            }
          }
          case notification {
            leaf notification-name {
              type union {
                type nacm-matchall-string-type;
                type string;
              }
              description
                "This leaf matches if its value equals the requested
                 notification name.";
            }
          }
          case path {
            leaf path {
              type schema-instance-identifier;
              mandatory true;
              description
                "Schema Instance Identifier associated with the data
                 node controlled by this rule.

                 Configuration data or state data instance identifiers
                 start with a top-level data node.  A complete
                 instance identifier is required for this type of path
                 value.

                 The special value '/' refers to all possible database
                 contents.";
            }
          }
        }

        leaf access-rights {
          type union {
            type nacm-matchall-string-type;
            type nacm-rights-type;
          }
          mandatory true;
          description
            "List of access rights granted to
             specified administrative groups for the
             content specified by the associated path.";
        }

        leaf action {
          type nacm-action-type;
          mandatory true;
          description
            "The access control action associated with the
             rule.  If a rule is determined to match a
             particular request, then this object is used
             to determine whether to permit or deny the
             request.";
        }
      }
    }
  }

Open issues:

  1.  Should it be possible for a rule-list to contain not just other
      rules, but also other rule-lists?  This would make it easier to
      build rule-lists out of smaller reusable pieces.

  2.  Would it be useful with any objects to help debug nacm?  E.g. an
      rpc to get all rules for a given group, or an rpc to check if a
      certain path will be permitted or denied for a given group,
      which also returns a trace of the rules tried that the execution
      pattern can be traced?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Mar 2011 09:45:44 -0700

Hi,

I like this new proposal, but I have 1 more optimization to suggest:

It would be good if the same rule could apply to multiple accessible
nodes to reduce configuration complexity.

Specifically, in the choice rule-type, if there were leaf-lists
instead of leafs (leaf-list rpc-name, notification-name, path),
as in this example:

  rule-list write-config {

     rule allow-editops {
          module-name ietf-netconf;
          rpc-name edit-config;
          rpc-name copy-config;
          rpc-name delete-config;
          rpc-name commit;
          rpc-name discard-changes;
          access-rights [exec];
	    action permit;
     }
  }

  rule-list read-config {
     allowed-group *;
     module-name ietf-netconf;
     rpc-name get;
     rpc-name get-config;
     access-rights [exec];
     action permit;
  }

  rule-list deny-edit-catch-all {
      allowed-group *;
      module-name ietf-netconf;
      rpc-name *;
      access-rights [exec];
      action deny;
  }

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Sunday, March 13, 2011 2:04 PM
To: [email-masked]
Subject: [Netconf] nacm proposal

Hi,

  rule-list networking {

   +--rw nacm
      +--rw rule-list [name]
         +--rw name             string

  container nacm {

    list rule-list {
      key "name";
      ordered-by user;

      description

      leaf name {
        type string {
          length "1..255";
        }
        description

      
      list rule {
        key "name";
        ordered-by user;

        description

        leaf name {
          type string {
            length "1..255";
          }
          description

        choice rule-type {
          description

        leaf access-rights {
          type union {

        leaf action {
          type nacm-action-type;
          mandatory true;
          description

Open issues:

/martin
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf