Hi ALTOers,

>From the discussion about the ALTO O&M draft last week, we find there is
another open issue that we should solve before we request YANG doctor
reviews:

According to Section 16.2.4 of RFC7285 and Requirement R5-3 of the ALTO O&M
draft, the data model should support configuration for access control at
the information resource level. In other words, the data model should
configure:

1. How an ALTO server identifies an ALTO client?
2. Which ALTO clients can access a given information resource?

To realize them, we consider two design options:

---

Option 1: authentication and authorization based approach

- To realize the first one, conceptually, we should provide data model to
configure authentication and authorization for each client. It can be
simply based on username and password, or delegated to other more complex
authentication systems like openID and LDAP.

- To realize the second one, a simple approach is to use a role-based
solution. Every authenticated client can be assigned to multiple roles. And
each information resource can configure to be accessible by given roles.

The YANG module can be like the following:

+--rw alto!
   +--rw alto-server
      ...
      +--rw auth-client* [username]
      |  +--rw username string
      |  +--rw (auth-config)
      |      +--:(basic-auth)
      |      |  +--rw username string
      |      |  +--rw password string
      |      ...
      |  +--rw role* role-name
      +--rw resource* [resource-id]
         ...
         +-- rw accepted-role* role-name
         ...

The choice auth-config can be augmented for different authentication
protocols.

We can reference or even reuse the openconfig-aaa data mode [1].

[1]
https://github.com/openconfig/public/blob/master/release/models/system/openconfig-aaa.yang

---

Option 2: ACL based approach

This approach only requires the server to configure an ACL. We can reuse
the YANG data model defined by RFC8519 [2]. It only filters the traffic by
the packet attributes, not the application-level authentication. Compared
with option 1, it may lose some fine-grained control. But for some simple
use cases like CDN or cloud networks, it may be good enough.

[2]: https://datatracker.ietf.org/doc/html/rfc8519

---

We are looking forward to seeing comments or suggestions on this open issue
from the WG.

Best regards,
Jensen on behalf of coauthers of ALTO O&M draft
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Reply via email to