[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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:
Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?





_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



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
Sent: Wednesday, July 16, 2014 2:33 PM
To: Rob Adams
Cc: controller-dev@...; aaa-dev@...; Reinaldo Penno
Subject: Re: [Aaa-dev] [controller-dev] How to prevent the use of RESTconf from certain generated models?

 

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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:

Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?




 

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


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:

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
Sent: Wednesday, July 16, 2014 2:33 PM
To: Rob Adams
Cc: controller-dev@...; aaa-dev@...; Reinaldo Penno
Subject: Re: [Aaa-dev] [controller-dev] How to prevent the use of RESTconf from certain generated models?

 

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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:

Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?




 

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 



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:
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:

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
Sent: Wednesday, July 16, 2014 2:33 PM
To: Rob Adams
Cc: controller-dev@...; aaa-dev@...; Reinaldo Penno
Subject: Re: [Aaa-dev] [controller-dev] How to prevent the use of RESTconf from certain generated models?

 

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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:

Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?




 

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 



_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



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:
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:
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:

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
Sent: Wednesday, July 16, 2014 2:33 PM
To: Rob Adams
Cc: controller-dev@...; aaa-dev@...; Reinaldo Penno
Subject: Re: [Aaa-dev] [controller-dev] How to prevent the use of RESTconf from certain generated models?

 

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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:

Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?




 

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 



_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
Aaa-dev mailing list
Aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Reinaldo Penno <rapenno@...>
 


On 7/21/14, 7:16 AM, Wojciech Dec wrote:
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.

[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. 

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.

[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.

 



My 2c,
Wojciech.




On 17 July 2014 05:21, Tom Pantelis <tompantelis@...> wrote:
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:
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:

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
Sent: Wednesday, July 16, 2014 2:33 PM
To: Rob Adams
Cc: controller-dev@...; aaa-dev@...; Reinaldo Penno
Subject: Re: [Aaa-dev] [controller-dev] How to prevent the use of RESTconf from certain generated models?

 

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:
https://wiki.opendaylight.org/view/AAA:Helium

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:
git clone https://git.opendaylight.org/gerrit/aaa

--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:

Summary: I use yang modeling sometimes because I like the auto-generated code, integration with datastore and APIs but *I do not want external users being able to perform any operations through RESTconf.*

Basically all entries on this datastore should be done only programmatically by my Provide-consumer code using the Yang generated APIs.

 Is there a way to do that today?




 

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

 



_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
Aaa-dev mailing list
Aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev