Date   

Re: [controller-dev] How to prevent the use of RESTconf from certain generated models?

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

 


Re: [controller-dev] How to prevent the use of RESTconf from certain generated models?

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

 



Re: [controller-dev] How to prevent the use of RESTconf from certain generated models?

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



Re: [controller-dev] How to prevent the use of RESTconf from certain generated models?

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



AAA Design Blueprint

Wojciech Dec
 

Hi All,

together with Liem we've put together the AAA design blueprint - it's also posted on our aaa wiki. We welcome your feedback:

https://drive.google.com/file/d/0B2IWJPwtf67LeDd5a0JrZkpNaHc/edit?usp=sharing

Regards,
Wojciech.


AAA actors & interaction

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi everyone,

 

As we ramped up on documentation, one thing (among others J) I notice lacking from our documentation is the interaction of different actors/external systems with the AAA system.  So, I took the liberty to document it here:

 

https://drive.google.com/file/d/0B1KtwIIbDsZXSS04UVJLQ1hqbVk/edit?usp=sharing

 

I think this would nicely compliment our design blueprint, which deals more with the inner workings of the AAA system.

 

Comments/questions are welcome.

 

Thanks,

Liem


Federated IdP attribute mapping proposal

John Dennis
 

I've been working on adding federated authentication. One of the
requirements is the ability to receive attributes from an external IdP
and map them into the roles and other attributes used internally by
OpenDaylight. An administrator will author a set of rules, one for each
external IdP which will defined how the foreign attributes are mapped.

We looked to other authentication/authorization systems for guidance, in
particular Openstack's federation support in Keystone and my experience
with RADIUS.

I would like you to review the proposed solution which is documented here:

http://jdennis.fedorapeople.org/federated_mapping/mapping.html

I have a working proof-of-concept implementation written in Python
(because Python is the language of OpenStack and this will also be
proposed for OpenStack and because I was able to do rapid prototyping in
Python allowing me to flesh out ideas quickly). Provided the proposal is
acceptable the idea is to implement it in Java. If the proposal is also
accepted in OpenStack I'll likely maintain 2 parallel implementations,
one in Python and one in Java.

You may find it instructional to initially read this introductory
document which explains the rationale for the approach taken and
possible alternatives.

http://jdennis.fedorapeople.org/federated_mapping/strategy.html

You will note I discuss 2 different possible solutions, scripts and
rules. The above proposal is rule based because several people I had
discussions with felt scripts were an advanced feature and I should
concentrate on something simpler. As you can see from the proposal I'm
not sure the rule based system is simpler to implement or use. In fact
I'm still of the opinion a script based system is easier to implement,
easier to use and will have fewer potential bugs.

--
John


AAA Meetings?

Ed Warnicke (eaw) <eaw@...>
 

Guys,
I just went looking for the AAA meeting here:

and didn’t find it… could you update that page to list your meeting?

Ed


Re: AAA Meetings?

Wojciech Dec
 

Done.


On 24 July 2014 12:47, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
I just went looking for the AAA meeting here:

and didn’t find it… could you update that page to list your meeting?

Ed

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



Config subsystem tutorial

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Agenda:
Wojciech will be going over some simple example of how to use the config subsystem.
 
Google Hangout:
 
Thanks,
Liem
 


Re: [controller-dev] How to prevent the use of RESTconf from certain generated models?

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




Re: Federated IdP attribute mapping proposal

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi John,

 

Thanks for putting this together.  I like both approaches!  I think both have merits, strengths and weaknesses.

 

I like the template/rule-based approach for its simplicity; however, I think that we should limit its functionality to just sed/awk type transformation, because going beyond that (like embedding control/flow logics) makes it more complicated and diminishes the promised simplicity benefit of this approach...  Kinda reminds me of assembly language and microcode <shiver/> :)

 

However, I do recognize that for some "real-world" use-cases, we may have a need for control logics.  In these cases, my preference would be to use a scripting language that I am familiar with to express control logics rather than using JSON (which is intended to be a data exchange format, after all), for all the reasons you mentioned, including debuggability.

 

So, I think we can start out with just a set of awk/sed type rules to do simple transformations but also allow additional (pluggable) rules to be defined and evaluated elsewhere in an external script.  Not sure if you have looked into it, but Java does have a built-in Javascript engine that you can use to execute Javascript from within the JVM.  Java 6/7 uses the Rhino engine, while Java 8 uses the Nashorn engine which is supposed to be faster than Rhino:

 

http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html

 

As for security, we should be able to leverage Karaf security to gate access to the bundle that loads the script, assuming the embedded script engine is used.

 

Regards,

Liem

 

 

-----Original Message-----
From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of John Dennis
Sent: Wednesday, July 23, 2014 8:04 AM
To: aaa-dev@...
Subject: [Aaa-dev] Federated IdP attribute mapping proposal

 

I've been working on adding federated authentication. One of the requirements is the ability to receive attributes from an external IdP and map them into the roles and other attributes used internally by OpenDaylight. An administrator will author a set of rules, one for each external IdP which will defined how the foreign attributes are mapped.

 

We looked to other authentication/authorization systems for guidance, in particular Openstack's federation support in Keystone and my experience with RADIUS.

 

I would like you to review the proposed solution which is documented here:

 

http://jdennis.fedorapeople.org/federated_mapping/mapping.html

 

I have a working proof-of-concept implementation written in Python (because Python is the language of OpenStack and this will also be proposed for OpenStack and because I was able to do rapid prototyping in Python allowing me to flesh out ideas quickly). Provided the proposal is acceptable the idea is to implement it in Java. If the proposal is also accepted in OpenStack I'll likely maintain 2 parallel implementations, one in Python and one in Java.

 

You may find it instructional to initially read this introductory document which explains the rationale for the approach taken and possible alternatives.

 

http://jdennis.fedorapeople.org/federated_mapping/strategy.html

 

You will note I discuss 2 different possible solutions, scripts and rules. The above proposal is rule based because several people I had discussions with felt scripts were an advanced feature and I should concentrate on something simpler. As you can see from the proposal I'm not sure the rule based system is simpler to implement or use. In fact I'm still of the opinion a script based system is easier to implement, easier to use and will have fewer potential bugs.

 

--

John

 

_______________________________________________

Aaa-dev mailing list

Aaa-dev@...

https://lists.opendaylight.org/mailman/listinfo/aaa-dev


AAA NB API draft available for review...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi everyone,

 

As our M4 milestone (API freeze) is approaching next week (8/4), I have put together a list of NB APIs that we plan to expose for Helium:

 

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

 

Please update any API that you see missing or inaccurate…  Peter, if you can help me fill out the section on IdM, that would be great.  I have modified the IdM APIs a little bit from the original ones, primarily on removing “user_id” from the URL, since it is a PII item and should be encrypted appropriately.  So, we will use a header (ODL_USER_ID?) for that purpose.

 

Thanks,

Liem


AAA Project call

Wojciech Dec (wdec) <wdec@...>
 

When: Tuesday, July 29, 2014 7:00 PM-8:00 PM. (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

*~*~*~*~*~*~*~*~*~*

Hi All,


As discussed last week, I’m proposing to move this week’s call to tomorrow, and a slight different time to allow for the MD-SAL Project call.

Agenda is:

  • Ongoing project work items update
  • Intro to config subsystem
  • AOB

Regards,

Wojciech

+---+---+---+---+---+---+---+---+---+---+---+ 

Please do not edit text below this line. 

You are invited to an online meeting using WebEx. 


Meeting Number: 204800606 

Meeting Password: 111111 


------------------------------------------------------- 

To join this meeting (Now from mobile devices!) 

------------------------------------------------------- 

1. Go to https://cisco.webex.com/cisco/j.php?MTID=m9a6f265497e7d247075d5a37d3842e97


2. Enter the meeting password: 111111 

3. Click 'Join Now'. 

4. Follow the instructions that appear on your screen. 



---------------------------------------------------------------- 

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes 

---------------------------------------------------------------- 


The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. 


Please dial the local access number for your area from the list below: 

- San Jose/Milpitas (408) area: 525-6800 

- RTP (919) area: 392-3330 


------------------------------------------------------- 

To join the teleconference only 

------------------------------------------------------- 

1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. 


San Jose, CA: +1.408.525.6800 

RTP: +1.919.392.3330 


US/Canada: +1.866.432.9903 

United Kingdom: +44.20.8824.0117 


India: +91.80.4350.1111 

Germany: +49.619.6773.9002 


Japan: +81.3.5763.9394 

China: +86.10.8515.5666 


http://www.webex.com


CCP:+14085256800x204800606# 


IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.    


Canceled: Config subsystem tutorial

Nguyen, Liem Manh <liem_m_nguyen@...>
 

We have one at 10am instead.
 
Agenda:
Wojciech will be going over some simple example of how to use the config subsystem.
 
Google Hangout:
 
Thanks,
Liem
 


Re: AAA NB API draft available for review...

Mellquist, Peter <peter.mellquist@...>
 

Just completed adding the IDM APIs.

 

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

 

 

Peter.

 

From: Nguyen, Liem Manh
Sent: Monday, July 28, 2014 9:34 AM
To: aaa-dev@...
Cc: Sujatha Joseph; Mellquist, Peter
Subject: AAA NB API draft available for review...

 

Hi everyone,

 

As our M4 milestone (API freeze) is approaching next week (8/4), I have put together a list of NB APIs that we plan to expose for Helium:

 

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

 

Please update any API that you see missing or inaccurate…  Peter, if you can help me fill out the section on IdM, that would be great.  I have modified the IdM APIs a little bit from the original ones, primarily on removing “user_id” from the URL, since it is a PII item and should be encrypted appropriately.  So, we will use a header (ODL_USER_ID?) for that purpose.

 

Thanks,

Liem


Declined: ODL - Weekly AAA Project meeting

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi guys,
 
I am on PTO today (sorry for the short notice)…  Please have the meeting without me.
 
As for my status:
 
DID:
1) Got AAA integrated with Karaf… Still doing some more testing.  Will demo next week to team.
 
DOING:
2) Working on documentation
3) Adding Auditing hooks

BLOCKER:
None
 
Cheers,
Liem
 


Re: [OpenDaylight Discuss] On multi-tenancy support

Colin Dixon <colin@...>
 

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

--Colin


On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: [OpenDaylight Discuss] On multi-tenancy support

Rob Adams <readams@...>
 

Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.


On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:
I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

--Colin


On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Re: [OpenDaylight Discuss] On multi-tenancy support

Lenrow, Dave <david.lenrow@...>
 

Hi Luis,

I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.

 

Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.

 

In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.

 

Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.

 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 

 

It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.

 

 

 

Below is pasted an email from the discuss list discussing this as well

 

Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.

This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.

We presented this and got some good feedback from the TWS call on June 2.

 

What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:

 

The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.

The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.

The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.

The parent child relationship can be extended recursively to an arbitrary depth.

Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.

 

 

Email included below describes the vision of how this would work in general.

The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.

 

Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  

 

Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?

 

I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 

 

Bring it on!

-drl

 

 

 

From: Lenrow, Dave
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy

 

Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that

 

One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.

 

 

Facitlities Based Provider – Owns switches, servers, fibre, etc.

    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent

        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent

            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent

                Admin in business Unit – provides on-demand, self-service access to subset of BU resources

                    BU developer – consumes on-demand, self-service subset of BU resources

                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.

                            Application module – can do stuff within envelope of BUA parent.

                                Etc.

 

In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.

I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.

 

 

FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.

VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.

LargeCo can define which virtual networks are accessible to the Finance BU

FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet

BU dev can contain the number of instances of paystubprinter allowed on-demand.

PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface

App module can stream log data within storage contstraints from FinBU (great-grand-parent)

Etc.

 

Above is kind of goofy contrived example, so please send nit picking to /dev/null.

 

Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.

 

Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.

 

 

Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).

 

Do others feel that this vision is sensible and needs to get reflected in our requirements?

 

It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).

 

If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.

 

I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.

 

 

 

-drl

 

Dave Lenrow

Distinguished Architect

Advanced Technology Group - HP Networking

Hewlett-Packard, Littleton MA

+1 (617)-329-1861 (mobile)

david.lenrow@...

@dlenrow

 

 

 

 

 

From: Rob Adams [mailto:readams@...]
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support

 

Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

 

--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:

Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 

41 - 60 of 1823