Hi Jensen,
For what it's worth, rfc 9249 (NTP Yang, which I am a co-author of..) uses
ACL for similar access control.
module: ietf-ntp
+--rw ntp!
+--rw port? inet:port-number {ntp-port}?
+--rw refclock-master!
| +--rw master-stratum? ntp-stratum
+--rw authentication {authentication}?
| +--rw auth-enabled? boolean
| +--rw authentication-keys* [keyid]
| +--rw keyid uint32
| +--rw algorithm? identityref
| +--rw key
| | +--rw (key-string-style)?
| | +--:(keystring)
| | | +--rw keystring? string {deprecated}?
| | +--:(hexadecimal) {hex-key-string}?
| | +--rw hexadecimal-string? yang:hex-string
| +--rw istrusted? boolean
+--rw access-rules {access-rules}?
| +--rw access-rule* [access-mode]
| +--rw access-mode identityref
| +--rw acl? -> /acl:acls/acl/name
+--ro clock-state
Thanks!
Dhruv
On Tue, Dec 13, 2022 at 3:46 PM Jensen Zhang <jingxuan.n.zh...@gmail.com>
wrote:
> 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
