[controller-dev] How to prevent the use of RESTconf from certain generated models?
|
Colin Dixon <colin@...>
The AAA project is planning to deliver access control on top of the MD-SAL, and they have the current status listed as PoC on their release page: I'm cc'ing their dev list to see if there's a better answer than that. You could also just check out their code so far:https://wiki.opendaylight.org/view/AAA:Helium git clone https://git.opendaylight.org/gerrit/aaa
On Mon, Jul 14, 2014 at 12:40 PM, Rob Adams <readams@...> wrote:
|
|
|
|
Nguyen, Liem Manh <liem_m_nguyen@...>
Hi Reinaldo,
Yes, we plan to have RBAC over MD-SAL…. This is work in progress and not there in the code yet. For now, I think you can simply disable the sal-rest-connector bundle if you don’t want any RESTconf access.
Regards, Liem
From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...]
On Behalf Of Colin Dixon
The AAA project is planning to deliver access control on top of the MD-SAL, and they have the current status listed as PoC on their release page: I'm cc'ing their dev list to see if there's a better answer than that. You could also just check out their code so far: --Colin
On Mon, Jul 14, 2014 at 12:40 PM, Rob Adams <readams@...> wrote:
Put things in the operational store only. You can read but not write from restconf.
On Fri, Jul 11, 2014 at 5:03 PM, Reinaldo Penno <rapenno@...> wrote:
|
|
|
|
Reinaldo Penno <rapenno@...>
I do not want to disable REST, I want to selectively disallow REST for certain containers, models. Making some of them operational as Rob suggested can solve some but not all. An yang extension would solve this very quickly. I'll put in my bag of proposed Yang extensions for ODL.
On Wed, Jul 16, 2014 at 4:08 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:
|
|
|
|
Tom Pantelis
I think it's perfectly reasonable to allow for granular control of restconf behavior via meta-data (ie extensions) in the yang model. At my last company, we had similar use cases and functionality in our MD-SAL equivalent, ie you could individually disable create, put, delete (even read access) for any element in the model. In fact, we didn't even create a REST endpoint by default - you had to explicitly enable it via meta-data.
On Wed, Jul 16, 2014 at 7:13 PM, Reinaldo Penno <rapenno@...> wrote:
|
|
|
|
Wojciech Dec
Personally I find these cases a slippery slope, as in even with such yang
extensions in place that limit the exposure of some part of the data tree via protocol X, access would be still allowed to it via internal APIs which will inevitably see someone implement a protocol Y that uses such internal APIs. The AAA project is meant to address this by
allowing authorizations to be set not only in terms of the "role" of a
user (say admin) but also the "app" that is accessing the data. Current data model is described in: https://lists.opendaylight.org/pipermail/aaa-dev/2014-July/000036.html Thus, the lack of meta-extensions to Yang data models to cover "data exposure", can generally be a said to be a good thing if we assume that the data is meant to be accessed using multiple protocols which are not/should not be the concern of the data-model. If however say REST(Conf) is say the *only* protocol that we expect to be used (is it?) yang extensions a'la JAX-RS, etc would be of value. My 2c, Wojciech.
On 17 July 2014 05:21, Tom Pantelis <tompantelis@...> wrote:
|
|
|
|
Reinaldo Penno <rapenno@...>
On 7/21/14, 7:16 AM, Wojciech Dec
wrote:
[RP] Well, yes and no. In order to use the internal APIs the software needs to be inside ODL. So, the ODL admin has the option to not load the "new" bundle.
[RP] From a northbound perspective I highly doubt we will use anything else. I mean, somebody can implement something else but I doubt it will gain momentum, so not loading the new bundle is an easy solution. But more to your point, I understand your reasoning, but I also do not want to use a cannon to kill a mosquito. I want simple things to be simple. From RESTconf perspective I need simple "render/not-render" Yang tags. If ODL admin needs fine grained control, AAA is the way to go.
|
|
|