z.archive.aaa-dev@lists.opendaylight.org

Tech meeting today?

Nguyen, Liem Manh <liem_m_nguyen@...>

#21

Hi guys,

I don’t see a meeting for AAA on my calendar today… Are we having a tech meeting?

I think from last time, the agenda is going to include intro to MD-SAL and a presentation of current MD-SAL AuthZ work--if you are ready, Wojciech…

Anyone else has anything else to talk about?

Thanks,

Liem

Re: Tech meeting today?

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

#22

What time today? The MD-SAL meeting is at 9am PST... I'd be happy to help in intro-ing the MD-SAL to

the AAA team though :)

Ed

From: aaa-dev-bounces@... [aaa-dev-bounces@...] on behalf of Nguyen, Liem Manh [liem_m_nguyen@...]
Sent: Tuesday, June 24, 2014 8:48 AM
To: aaa-dev@...
Cc: Lenrow, Dave
Subject: [Aaa-dev] Tech meeting today?

Hi guys,

I don’t see a meeting for AAA on my calendar today… Are we having a tech meeting?

I think from last time, the agenda is going to include intro to MD-SAL and a presentation of current MD-SAL AuthZ work--if you are ready, Wojciech…

Anyone else has anything else to talk about?

Thanks,

Liem

Re: Tech meeting today?

Nguyen, Liem Manh <liem_m_nguyen@...>

#23

We occasionally have AAA tech meetings at 9PST on Tuesdays… Guess that conflicts with MD-SAL meeting :\.

I will move this topic for this Thursday then… and we need a new date/time for tech meeting. Mondays from 8:30AM PST – 9:30AM PST ok with folks?

Liem

From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, June 24, 2014 7:34 AM
To: Nguyen, Liem Manh; aaa-dev@...
Cc: Lenrow, Dave
Subject: RE: Tech meeting today?

What time today? The MD-SAL meeting is at 9am PST... I'd be happy to help in intro-ing the MD-SAL to

the AAA team though :)

Ed

From: aaa-dev-bounces@... [aaa-dev-bounces@...] on behalf of Nguyen, Liem Manh [liem_m_nguyen@...]
Sent: Tuesday, June 24, 2014 8:48 AM
To: aaa-dev@...
Cc: Lenrow, Dave
Subject: [Aaa-dev] Tech meeting today?

Hi guys,

I don’t see a meeting for AAA on my calendar today… Are we having a tech meeting?

I think from last time, the agenda is going to include intro to MD-SAL and a presentation of current MD-SAL AuthZ work--if you are ready, Wojciech…

Anyone else has anything else to talk about?

Thanks,

Liem

time change for AAA meetings on Thursdays

Nguyen, Liem Manh <liem_m_nguyen@...>

#24

Hi guys,

My kid’s summer camp schedule throws me for a loop, and I need to move the AAA status meetings on Thursdays 1/2 hour early (8:30AM PST instead of 9AM), at least for the next couple of months. Is that ok with folks?

Thanks,

Liem

Re: time change for AAA meetings on Thursdays

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

#25

I would be :)

Ed

From: aaa-dev-bounces@... [aaa-dev-bounces@...] on behalf of Nguyen, Liem Manh [liem_m_nguyen@...]
Sent: Tuesday, June 24, 2014 10:34 AM
To: aaa-dev@...
Subject: [Aaa-dev] time change for AAA meetings on Thursdays

Hi guys,

My kid’s summer camp schedule throws me for a loop, and I need to move the AAA status meetings on Thursdays 1/2 hour early (8:30AM PST instead of 9AM), at least for the next couple of months. Is that ok with folks?

Thanks,

Liem

Re: Tech meeting today?

John Dennis

#26

On 06/24/2014 11:31 AM, Nguyen, Liem Manh wrote:

We occasionally have AAA tech meetings at 9PST on Tuesdays… Guess that conflicts with MD-SAL meeting :\.

I will move this topic for this Thursday then… and we need a new date/time for tech meeting. Mondays from 8:30AM PST – 9:30AM PST ok with folks?

works for me

-- 
John

Re: time change for AAA meetings on Thursdays

John Dennis

#27

On 06/24/2014 11:34 AM, Nguyen, Liem Manh wrote:

Hi guys,

My kid’s summer camp schedule throws me for a loop, and I need to move the AAA status meetings on Thursdays 1/2 hour early (8:30AM PST instead of 9AM), at least for the next couple of months. Is that ok with folks?

Ok for me

-- 
John

ODL - Weekly AAA Project meeting

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

#28

When: Thursday, June 26, 2014 5:30 PM-6:30 PM. (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna *~*~*~*~*~*~*~*~*~*

Agenda:

Status (https://trello.com/b/ehBCSGY3/opendaylight-aaa)
What was done?
What is being worked on?
Blockers?
Other topics (as time allows or leading to separate meetings)

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

Please do not edit text below this line.

You are invited to an online meeting using WebEx.

Meeting Number: 201443156

Meeting Password: 111111

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

To join this meeting (Now from mobile devices!)

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

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

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:+14085256800x201443156#

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.

Calendar

Re: time change for AAA meetings on Thursdays

Wojciech Dec

#29

Just sent out an updated invite...

Show quoted text

On 24 June 2014 17:34, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi guys,

My kid’s summer camp schedule throws me for a loop, and I need to move the AAA status meetings on Thursdays 1/2 hour early (8:30AM PST instead of 9AM), at least for the next couple of months. Is that ok with folks?

Thanks,

Liem

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

Re: ODL - Weekly AAA Project meeting

Nguyen, Liem Manh <liem_m_nguyen@...>

#30

Hi guys,

Proposed agenda (in addition to status) for tomorrow:

Update on MD-SAL AuthZ design/progress

I added a decorator for BlockingQueue to help with auth context transfer across thread boundaries, like in the case of ThreadPoolExecutors… See the usage of the decorator in the JUnit testSecureThreadPoolExecutor method for an example.

Cheers,

Liem

-----Original Appointment-----
From: Wojciech Dec (wdec) [mailto:wdec@...]
Sent: Wednesday, June 25, 2014 7:21 AM
To: Wojciech Dec (wdec); Nguyen, Liem Manh; Abhishek Kumar (abhishk2); 'Arash Eghtesadi'; John Dennis; Lakshman Mukkamalla (lmukkama); Lenrow, Dave; Mellquist, Peter; aaa-dev@...
Subject: ODL - Weekly AAA Project meeting
When: Thursday, June 26, 2014 5:30 PM-6:30 PM (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna.
Where:

When: Thursday, June 26, 2014 5:30 PM-6:30 PM. (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

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

Agenda:

Status (https://trello.com/b/ehBCSGY3/opendaylight-aaa)

What was done?

What is being worked on?

Blockers?

Other topics (as time allows or leading to separate meetings)

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

Please do not edit text below this line.

You are invited to an online meeting using WebEx.

Meeting Number: 201443156

Meeting Password: 111111

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

To join this meeting (Now from mobile devices!)

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

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

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:+14085256800x201443156#

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.

Re: time change for AAA meetings on Thursdays

John Dennis

#31

The meeting was moved up 1/2 hour but the webex link in the meeting
invite still thinks the meeting is at the original time and is not
allowing me to connect early.

-- 
John

Re: time change for AAA meetings on Thursdays

Nguyen, Liem Manh <liem_m_nguyen@...>

#32

Yep, same issue here...  Wojciech needs to change it, since I am not the host.

Liem

Show quoted text

-----Original Message-----
From: John Dennis [mailto:jdennis@...] 
Sent: Thursday, June 26, 2014 8:34 AM
To: Wojciech Dec; Nguyen, Liem Manh
Cc: aaa-dev@...
Subject: Re: [Aaa-dev] time change for AAA meetings on Thursdays

The meeting was moved up 1/2 hour but the webex link in the meeting invite still thinks the meeting is at the original time and is not allowing me to connect early.

--
John

Re: time change for AAA meetings on Thursdays

Nguyen, Liem Manh <liem_m_nguyen@...>

#33

Looks like it's working now... 

Liem

Show quoted text

-----Original Message-----
From: Nguyen, Liem Manh 
Sent: Thursday, June 26, 2014 8:35 AM
To: 'John Dennis'; Wojciech Dec
Cc: aaa-dev@...
Subject: RE: [Aaa-dev] time change for AAA meetings on Thursdays

Yep, same issue here...  Wojciech needs to change it, since I am not the host.

Liem

-----Original Message-----
From: John Dennis [mailto:jdennis@...] 
Sent: Thursday, June 26, 2014 8:34 AM
To: Wojciech Dec; Nguyen, Liem Manh
Cc: aaa-dev@...
Subject: Re: [Aaa-dev] time change for AAA meetings on Thursdays

The meeting was moved up 1/2 hour but the webex link in the meeting invite still thinks the meeting is at the original time and is not allowing me to connect early.

--
John

Re: Change in aaa[master]: Added IdmLight place-holder and OSGi proxy for IdmLight inte...

Nguyen, Liem Manh <liem_m_nguyen@...>

#34

FYI...  Some minor refactoring so we are consistent in terms of naming (no more "tenant").  This has been pushed into master.

Cheers,
Liem

Show quoted text

-----Original Message-----
From: Gerrit Code Review [mailto:gerrit@...] 
Sent: Wednesday, July 02, 2014 11:09 AM
To: Nguyen, Liem Manh
Subject: Change in aaa[master]: Added IdmLight place-holder and OSGi proxy for IdmLight inte...

From jenkins-aaa <jenkins-aaa@...>:

jenkins-aaa has posted comments on this change.

Change subject: Added IdmLight place-holder and OSGi proxy for IdmLight integration.  Refactored renaming tenant -> domain.
......................................................................


Patch Set 1: Verified+1

Build Successful 

https://jenkins.opendaylight.org/aaa/job/aaa-verify/11/ : SUCCESS

-- 
To view, visit https://git.opendaylight.org/gerrit/8567
To unsubscribe, visit https://git.opendaylight.org/gerrit/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I148963affe684bb9510ff1bcebf22d8e3d836a71
Gerrit-PatchSet: 1
Gerrit-Project: aaa
Gerrit-Branch: master
Gerrit-Owner: Liem Nguyen <liem_m_nguyen@...>
Gerrit-Reviewer: jenkins-aaa <jenkins-aaa@...>
Gerrit-HasComments: No

Authorization model

Wojciech Dec

#35

Hi Folks,

here's the initial authorization model, that I would like to propose for starters. Key inputs exected to be provided by the AuthN sub-system are: role and domain-name.

The idea is that the AuthZ system would use these and run an authorization check against the service, designated by service-name, that has triggered the AuthZ action.

The model allows for chaining of authz policies, via an ordered list of references to such policies.

The simple-authorization node is there for demo purposes only - it forms the core domain-agnostic authz policy model, which would be reusable by components wishing to extend it, etc.

module: authorization-data-schema
   +--rw domain-authorizations
   | +--rw domains* [domain-name]
   |     +--rw domain-name           domain-type
   |     +--rw policies* [service action]
   |     | +--rw service      service-type
   |     | +--rw action       action-type
   |     | +--rw resources    resource-type
   |     | +--rw role         role-type
   |     +--rw authz-domain-chain* [domain-name]
   |        +--rw domain-name    leafref
   +--rw simple-authorization
      +--rw policies* [service action]
         +--rw service      service-type
         +--rw action       action-type
         +--rw resources    resource-type
         +--rw role         role-type

Yang file attached.

Regards,
Wojciech.

authorization-data-schema.yang

AuthZ service - REST(Conf) accessible or not?

Wojciech Dec

#36

Hi Folks,

while working through the config sub-system wiring, I came to a question that calls for some wider input. As far as I understand, there are two types of wiring API ends that can be used a) Yang RPC derived b) manually defined. (The Toaster model exemplifies only the former)
Now, the advantage of the former is that the wiring automatically gets made with other services, eg RestConf. But it occured to me, is this necessary for the AuthZ service, i.e. would we want to expose the AuthZ service to external queries arriving over REST of the type: Can user X perform Y on Z?

Thoughts?

Cheers,

Wojciech.

Re: Authorization model

Wojciech Dec

#37

Hi All,

given that this is an initial model, I'm collecting your feedback on, and mindful of the fact that Yang syntax might be new to some, here's some additional description.

The Yang model consists of two main data structures:

- A simple Authorization node: This contains the key/basic authorization data model, in the form of a list that is keyed by a "service" and "action". More on these later one

- A domain authorization node: This contains a list of the basic authorizations, but in a per domain form, with the key being a domain. In addition, for each list item, there is an additional list, authz-domain-chain, containing an ordered list of references to additional domain policies that are applicable for this domain.

The "service" data item, is intended to respresent an ODL service component that is effectively invoking an authZ request. Eg, if an authN user, joe@... is making some request via the REST interface, the "service" would be REST(conf). If the same user was doing a request over Netconf, the "service" would be Netconf. Naturally, we need to arrive at some naming convention for services, perhaps bundle names.

The "action" is an item off the enumerated list (crud, none, all) representing the requested action. With this model client would be responsible for mapping their service specific request (eg PUT) to such an action (eg create).

About the Authz chain. The list is user-ordered, meaning that the order of the entries is intended to be set by the writer into that list. I'm thinking that one likely chain would be to actually make this list an explicitly priority ordered list, by introducing a "priority" data item.
The API to the AuthZ service engine is not captured by the above model, but that will be a next step if we agree that the above is a decent base.

Example of an AuthZ chain: Suppose foo.com is using the services of bar.com, who in term use abc.com. Each of the "lower tier" providers would represent their customer policies as customers.bar.com and customers.abc.com.

When joe@... makes a request to read X using service Y, the conceptual AuthZ service engine would use the data from the foo.com entry on the domain-authz list, to evaluate in a first instance the authz for foo.com as key. Finding that this policy contains an ordered list comprised of customers.bar.com and customers.abc.com, each of those policies are retrieved from the domain-authz list (using customers.bar.com and customers.abc.com as key).

Conceptually the data model does not deal with conflict resolution, leaving such processing to the service engine. Alternatively policy conflict resolution checks could be be applied upon policy insertion. The data model is neutral to which of these methods is chosen.

Welcome your feedback.

Regards,

Wojciech.

Show quoted text

On 3 July 2014 17:02, Wojciech Dec <wdec.ietf@...> wrote:

Hi Folks,

here's the initial authorization model, that I would like to propose for starters. Key inputs exected to be provided by the AuthN sub-system are: role and domain-name.

The idea is that the AuthZ system would use these and run an authorization check against the service, designated by service-name, that has triggered the AuthZ action.

The model allows for chaining of authz policies, via an ordered list of references to such policies.

The simple-authorization node is there for demo purposes only - it forms the core domain-agnostic authz policy model, which would be reusable by components wishing to extend it, etc.

module: authorization-data-schema
   +--rw domain-authorizations
   | +--rw domains* [domain-name]
   |     +--rw domain-name           domain-type
   |     +--rw policies* [service action]
   |     | +--rw service      service-type
   |     | +--rw action       action-type
   |     | +--rw resources    resource-type
   |     | +--rw role         role-type
   |     +--rw authz-domain-chain* [domain-name]
   |        +--rw domain-name    leafref
   +--rw simple-authorization
      +--rw policies* [service action]
         +--rw service      service-type
         +--rw action       action-type
         +--rw resources    resource-type
         +--rw role         role-type

Yang file attached.

Regards,
Wojciech.

Re: AuthZ service - REST(Conf) accessible or not?

Nguyen, Liem Manh <liem_m_nguyen@...>

#38

Hi Wojciech,

I don’t really see a use-case for exposing AuthZ via REST… In fact, I think it might be a security issue, since it exposes too much of the inner workings of the AAA system for a potential hacker if they get a hold of this information. From the resource owner’s perspective, they should already know what kind of accesses they should get with the given role(s).

From the AAA admin’s perspective, however, I think CRUD APIs over the access policies would be beneficial.

Thoughts?

Regards,

Liem

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Wojciech Dec
Sent: Friday, July 04, 2014 9:22 AM
To: aaa-dev@...
Subject: [Aaa-dev] AuthZ service - REST(Conf) accessible or not?

Hi Folks,

while working through the config sub-system wiring, I came to a question that calls for some wider input. As far as I understand, there are two types of wiring API ends that can be used a) Yang RPC derived b) manually defined. (The Toaster model exemplifies only the former)
Now, the advantage of the former is that the wiring automatically gets made with other services, eg RestConf. But it occured to me, is this necessary for the AuthZ service, i.e. would we want to expose the AuthZ service to external queries arriving over REST of the type: Can user X perform Y on Z?

Thoughts?

Cheers,

Wojciech.

How to authenticate

Wojciech Dec

#39

Hi Liem,

after updating my repo to the latest, I noticed that the authentication "curl" instructions no longer work, and I cannot get past the auth stage. Looking at the code the new IdMService now seems to have the 1234 user.

Could you please advise how to get a token in this system? (Would be good to update the readme too)

Regards,
Wojciech.

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

Colin Dixon <colin@...>

#40

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

Show quoted text

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