Date   

OpenDaylight New Project Startup Help

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

When: Friday, May 30, 2014 11:00 AM-12:00 PM. (UTC-06:00) Central Time (US & Canada)

*~*~*~*~*~*~*~*~*~*
Guys,
    As  I suggested here:
I'm willing to provide a helping hand to new projects looking to get going with the ODL
infra (setup Jenkins jobs etc).  I didn't get any direct response back to that email, but the SNBI team
was interested in doing it Friday morning at 9am.  I wanted to throw this open to any new project committers
who'd like to show up to also work on infra setup for their projects.

       Expect a bit of chaos, as it will be folks working on getting stuff done live, but hopefully folks will find it useful :)

       It may be useful to preview:

       Its not as complete as I'd like... but its something to start chewing on :)

In addition I would strongly recommend that folks turn up in #opendaylight-meeting on IRC
as well :)

Ed


You are the host for this online meeting.

Topic: ODL New Project Setup Help
Date: Friday, May 30, 2014
Time: 11:00 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 200 735 855
Meeting Password: default
Host Key: 113271 (use this to reclaim host privileges)

-------------------------------------------------------
To start the online meeting
-------------------------------------------------------
2. Log in to your account.
3. Click "Start Now".
4. Follow the instructions that appear on your screen.

----------------------------------------------------------------
ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES
----------------------------------------------------------------
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

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
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

-------------------------------------------------------
For assistance
-------------------------------------------------------
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft Outlook), click this link:

To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/ciscosales/systemdiagnosis.php.


CCM:+14085256800x200735855#

-------------------------------------------------------
To invite others to join
-------------------------------------------------------

....................Start copying here...................

Topic: ODL New Project Setup Help
Date: Friday, May 30, 2014
Time: 11:00 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 200 735 855
Password: default

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: default
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800

Access code:200 735 855




CCP:+14085256800x200735855#

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.
....................Stop copying here ...................


Prep for the M2 milestone

Phil Robb <probb@...>
 

Hello Liem and the developers on the AAA project.

In looking at the AAA release plan, I was surprised that there were no dependencies documented on other projects given that AAA will need to integrate with network services, the SAL, etc within ODL.

Do I have it wrong, or are there dependencies and collaborations that need to occur between AAA and the other projects and are those collaborations planned and on-track?

Thanks,

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Prep for the M2 milestone

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Phil,

 

We will document dependencies before M2.  Thanks for the reminder!

 

Liem

 

From: Phil Robb [mailto:probb@...]
Sent: Monday, June 02, 2014 10:18 PM
To: Nguyen, Liem Manh; aaa-dev@...
Subject: Prep for the M2 milestone

 

Hello Liem and the developers on the AAA project.

 

In looking at the AAA release plan, I was surprised that there were no dependencies documented on other projects given that AAA will need to integrate with network services, the SAL, etc within ODL.

 

Do I have it wrong, or are there dependencies and collaborations that need to occur between AAA and the other projects and are those collaborations planned and on-track?

 

Thanks,

 

Phil.
--

Phil Robb

Director - Networking Solutions

The Linux Foundation

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb


Re: Prep for the M2 milestone

Phil Robb <probb@...>
 

Thanks Liem, and you are very welcome.

Phil.


On Tue, Jun 3, 2014 at 11:37 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Phil,

 

We will document dependencies before M2.  Thanks for the reminder!

 

Liem

 

From: Phil Robb [mailto:probb@...]
Sent: Monday, June 02, 2014 10:18 PM
To: Nguyen, Liem Manh; aaa-dev@...
Subject: Prep for the M2 milestone

 

Hello Liem and the developers on the AAA project.

 

In looking at the AAA release plan, I was surprised that there were no dependencies documented on other projects given that AAA will need to integrate with network services, the SAL, etc within ODL.

 

Do I have it wrong, or are there dependencies and collaborations that need to occur between AAA and the other projects and are those collaborations planned and on-track?

 

Thanks,

 

Phil.
--

Phil Robb

Director - Networking Solutions

The Linux Foundation

Skype: Phil.Robb




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Invitation: OpenDaylight New Project Startup Help @ Thu Jun 5, 2014 12:30am - 1:30am (probb@linuxfoundation.org)

Philip Robb <probb@...>
 

OpenDaylight New Project Startup Help

The goal of this meeting is to help projects that are new to OpenDaylight setup and begin to use their infrastructure (git/gerrit/jenkins/etc).

Access Information
Where: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M06MF41IDD3ONTOZEZHYUN9MZS-9VIB&rnd=411377.06615

Meeting number: 194 652 780
Password: This meeting does not require a password.
Host key: 632775 (Use this key in the meeting if you have made someone else the host and then want to reclaim the host role.)

Audio Connection
1-855-244-8681 Call-in toll-free number (US/Canada)
1-650-479-3207 Call-in toll number (US/Canada)
Access code: 194 652 780

When
Thu Jun 5, 2014 12:30am – 1:30am Hong Kong
Where
See body of invitation (map)
Video call
https://plus.google.com/hangouts/_/linuxfoundation.org/probb
Calendar
probb@...
Who
Philip Robb - organizer
snbi-dev@...
rafat.jahan@...
Andrew Grimberg
l2switch-dev@...
eaw@...
ttp-dev@...
Mathieu Lemay
aaa-dev@...
Andrew Kim
paulq@...
cdixon@...
Aric Gardner
opflex-dev@...
reservation-dev@...
liem_m_nguyen@...
sfc-dev@...
fbrockne@...
sdninterfaceapp@...
Don Kehn

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account aaa-dev@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


AAA project dependencies...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi guys,

 

I updated the Wiki page to include some potential integration areas with other projects:

 

https://wiki.opendaylight.org/view/AAA:Helium#Expected_Dependencies_on_Other_Projects

 

Please add more if I miss anything…

 

Thanks,

Liem

 

PS:  Also, please subscribe to the spanking new aaa-dev@... mailing list! J


Resend: AAA project dependencies...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Sorry for spamming if you got this twice… There was a hiccup with the mailing list.

 

Hi guys,

 

I updated the Wiki page to include some potential integration areas with other projects:

 

https://wiki.opendaylight.org/view/AAA:Helium#Expected_Dependencies_on_Other_Projects

 

Please add more if I miss anything…

 

Thanks,

Liem

 

PS:  Also, please subscribe to the spanking new aaa-dev@... mailing list! J

 


ODL - Weekly AAA Project meeting

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

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

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

Agenda:

  1. Status (https://trello.com/b/ehBCSGY3/opendaylight-aaa)
  2. What was done?
  3. What is being worked on?
  4. Blockers?
  5. 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.    


ODL AAA Project

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

When: Tuesday, June 17, 2014 6:00 PM-7:00 PM. (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

*~*~*~*~*~*~*~*~*~*
Additional call…

Likely agenda:
  • Continue current code discussion / design
  • Overview of possible integration with MD-SAL

  • +---+---+---+---+---+---+---+---+---+---+---+ 
  • Please do not edit text below this line. 
  • You are invited to an online meeting using WebEx. 

  • Meeting Number: 202295972 
  • Meeting Password: 123456 

  • ------------------------------------------------------- 
  • To join this meeting (Now from mobile devices!) 
  • ------------------------------------------------------- 
  • 1. Go to https://cisco.webex.com/cisco/j.php?MTID=mda9a918653145d17bad2964bd0466943

  • 2. Enter the meeting password: 123456 
  • 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 


CCP:+14085256800x202295972#

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.   


Musings about passing SecurityContexts between threads

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

Guys,
At the AAA meeting this week, as Liem was walking us through the code, he showed us attaching
security context to an InheritableThreadLocal store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and executors where you may pass
work from one thread to another, but not by spawning new threads. I had mused about that being worrisome
to me, because it requires folks to get it right at many many places in the code every time work is passed between
threads, but that I didn’t have a smarter idea, and that might be the state of what could be done. (which is to say, as a matter of personal
technical opinion I made mild grumbly noises, but couldn’t be constructive about helping to move things
forward and so appropriately didn’t press it much past making my grumble known ;) ).

I still don’t have a better way… but was curious if other folks had any thoughts/experience to share as to
other options and the tradeoffs in them?

Ed


Re: Musings about passing SecurityContexts between threads

Kent Watsen <kwatsen@...>
 

I missed that meeting and thus don't have context, but my first question
is why do you need to do this at all? That is, in my world-view, the
incoming northbound request is steered to the appropriate service for
processing. That service is responsible to enforcing access-control, and
does so without other services needing to do any additional enforcement.

For instance, let's say you have a service that can generate pretty CIO
reports off data persisted by an analytics service. Furthermore, let's
say that the particular user sending the request is only allowed to see a
subset of the data (e.g. tenant=="pepsi" && device-type=="firewall"). So
we might have:

User Reporting Service Analytics Service
| | |

| | |
| | |
| Generate report | |
| over all data | |
|------------------>| |

| | |

| | |

| | Get data where |

| | tenant=="pepsi" && |
| | device-type=="firewall" |

| |------------------------->|

| | |

| | |



So no need for an internal call to pass a security context. Can it not
be the same here?


Thanks,
Kent

On 6/13/14, 4:10 PM, "Ed Warnicke (eaw)" <eaw@cisco.com> wrote:

Guys,
At the AAA meeting this week, as Liem was walking us through the code,
he showed us attaching
security context to an InheritableThreadLocal store (meaning, its context
is the thread or its children).
We talked a bit about how that interacts with thread pools and executors
where you may pass
work from one thread to another, but not by spawning new threads. I had
mused about that being worrisome
to me, because it requires folks to get it right at many many places in
the code every time work is passed between
threads, but that I didn¹t have a smarter idea, and that might be the
state of what could be done. (which is to say, as a matter of personal
technical opinion I made mild grumbly noises, but couldn¹t be
constructive about helping to move things
forward and so appropriately didn¹t press it much past making my grumble
known ;) ).

I still don¹t have a better wayŠ but was curious if other folks had any
thoughts/experience to share as to
other options and the tradeoffs in them?

Ed


Re: Musings about passing SecurityContexts between threads

Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
 

I think that would call for a set of implementation which will talk to the ThreadLocal context, e.g. ExecutorService.submit() would look at the store and attach the current context to the work being submitted and restore it when a thread picks up the work... It should not be hard to create such a decorator.

Bye,
Robert

-----Original Message-----
From: Ed Warnicke (eaw)
Sent: Friday, June 13, 2014 10:10 PM
To: aaa-dev@lists.opendaylight.org
Cc: Kent Watsen; Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco);
Nguyen, Liem Manh
Subject: Musings about passing SecurityContexts between threads

Guys,
At the AAA meeting this week, as Liem was walking us through the
code, he showed us attaching security context to an InheritableThreadLocal
store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and
executors where you may pass work from one thread to another, but not by
spawning new threads. I had mused about that being worrisome to me,
because it requires folks to get it right at many many places in the code
every time work is passed between threads, but that I didn't have a smarter
idea, and that might be the state of what could be done. (which is to say, as
a matter of personal technical opinion I made mild grumbly noises, but
couldn't be constructive about helping to move things forward and so
appropriately didn't press it much past making my grumble known ;) ).

I still don't have a better way... but was curious if other folks had any
thoughts/experience to share as to other options and the tradeoffs in
them?

Ed


Token-based authentication...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi everyone,

 

For Helium, AAA plans to deliver token-based authentication (vs what we do today which is HTTP basic).  An example of that is documented in the “Running” section of the AAA’s README.  Once authenticated, an access token (default expiration is 1 hour) is returned, which is then can be submitted for subsequent REST calls.

 

Our delivery schedule is here.  Please let us know if you have any questions on token-based authentication…

 

Thanks,

Liem


Re: [dlux-dev] Token-based authentication...

Harman Singh (harmasin) <harmasin@...>
 

We are using MD-SAL APIs for dlux. In your release plan there is still a question mark on that, as we know MD-SAL does not have any authentication. Once you update your plan for MD-SAL API’s authentication, please let us know as well. We will update our tasks too.

Thanks,
- Harman

From: <Nguyen>, Liem Manh <liem_m_nguyen@...>
Date: Monday, June 16, 2014 at 10:33 AM
To: "dlux-dev@..." <dlux-dev@...>
Cc: "aaa-dev@..." <aaa-dev@...>
Subject: [dlux-dev] Token-based authentication...

Hi everyone,

 

For Helium, AAA plans to deliver token-based authentication (vs what we do today which is HTTP basic).  An example of that is documented in the “Running” section of the AAA’s README.  Once authenticated, an access token (default expiration is 1 hour) is returned, which is then can be submitted for subsequent REST calls.

 

Our delivery schedule is here.  Please let us know if you have any questions on token-based authentication…

 

Thanks,

Liem


authn vs. authz

John Dennis
 

Hi Liem:

Thank you for sending out the sequence diagrams, they've been very
helpful. Also thank you for posting the code to a public git repo. The
code looks clean, nicely organized and professionally written. I've been
going through the code to get a better understanding of the overarching
architecture and I've got a few questions.

My first question is an organizational one, I noticed you've been
sending your emails with design information to specific individuals
instead of the aaa-dev list, is there a reason? FWIW I've sent this mail
to both the individuals you've been emailing *and* the aaa-dev list.
Should we be using the aaa-dev list from this point on?

The Framework Overview (https://github.com/opendaylight/aaa) is clear
that authentication (authn) and authorization (authz) are two
independent concepts and derive from independent sources of authority.
This is good, authn and authz should be separate.

But when I look at the code it looks to me as if authn and authz have
been conflated. I draw this conclusion by looking at the fields in the
Claim and Authentication types. An identity claim is something returned
by a trusted IdP (Identity Provider) which attests to the identity and
attributes bound to that identity by the IdP. It appears as if the Claim
type is being used for this purpose in the code. However the Claim type
also includes tenant and role information. An independent IdP will not
(or should not) have information specific to ODL. This is especially
true for roles, only ODL should know what the roles are and which
identities possess those roles. [1]

Perhaps I've misread the code (please correct me) but it looks as if
ClaimAuthFilter via the ClaimAuth.transform() method is supposed to map
from an IdP identity assertion to a Claim object. What is confusing me
is how or why would an external authn assertion know anything about the
ODL roles in order to populate the roles in the Claim object? [2]

It seems to me there needs to be a separate mapping stage which maps
from an identity assertion to ODL specific information such as tenant
and roles. As an example you might want to look at how Keystone handles
the federated case
(https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md).
In the Keystone federation architecture one binds an (IdP, protocol)
2-tuple to a mapping which maps from IdP attributes to those used
internally (i.e. groups, roles, etc.)

Going back to the code and the sequence diagrams shouldn't there be an
IdentityClaim (does not yet exist) which is passed to a mapping endpoint
(does not yet exist) which returns a Claim instead of the
ClaimAuthFilter attempting to assign roles and return a Claim?

Also, I'm not sure why we have the DirectAuth case as a special case
code path and flow. Couldn't the code be simplified if DirectAuth was an
instance of the federated case? Here the internal DirecAuth "toy" IdP
only does username/password authn and the roles are provided by a
mapping? Fewer code paths usually means more robust code.

I'm sure I have a slew of misunderstandings about how the actually code
works :-) Feel free to set me straight.

Thanks again for the great code and excellent diagrams!

John


[1] Allowing an IdP to attach a role to an identity is a security
concern. You may trust an IdP to authenticate a user but do you really
want to trust that IdP to also claim that user has the admin role in
your service? It may be case that you trust *some* IdP's to assign roles
but that should be configurable and off by default. I suspect the
DirectAuth case is one such example (correct?)

[2] It almost looks as if the authz processing is supposed to happen in
TokenEndpoint.createAccessToken() where the else clause says

// TODO: Support authorization code later...

but if the claim filters are setting the roles (which is my definition
of authz) then what authorization code is going to execute here?
--
John


Re: authn vs. authz

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi John,

 

My response in-line below…   

 

Cheers,

Liem

 

-----Original Message-----
From: John Dennis [mailto:jdennis@...]
Sent: Monday, June 16, 2014 3:39 PM
To: Nguyen, Liem Manh; Abhishek Kumar; 'Arash Eghtesadi'; Lakshman Mukkamalla; Lenrow, Dave; Mellquist, Peter; Wojciech Dec; aaa-dev@...; Nathan Kinder
Subject: authn vs. authz

 

Hi Liem:

 

Thank you for sending out the sequence diagrams, they've been very helpful. Also thank you for posting the code to a public git repo. The code looks clean, nicely organized and professionally written. I've been going through the code to get a better understanding of the overarching architecture and I've got a few questions.

 

My first question is an organizational one, I noticed you've been sending your emails with design information to specific individuals instead of the aaa-dev list, is there a reason? FWIW I've sent this mail to both the individuals you've been emailing *and* the aaa-dev list.

Should we be using the aaa-dev list from this point on?

 

>> Yes, I was not sure if everyone has subscribed to the aaa-dev list; so, I sent to individual addresses to make sure that the information does get to our team.  If everyone has got on the aaa-dev list (which I encourage folks to), it will make it simpler next time J

 

The Framework Overview (https://github.com/opendaylight/aaa) is clear that authentication (authn) and authorization (authz) are two independent concepts and derive from independent sources of authority.

This is good, authn and authz should be separate.

 

But when I look at the code it looks to me as if authn and authz have been conflated. I draw this conclusion by looking at the fields in the Claim and Authentication types. An identity claim is something returned by a trusted IdP (Identity Provider) which attests to the identity and attributes bound to that identity by the IdP. It appears as if the Claim type is being used for this purpose in the code. However the Claim type also includes tenant and role information. An independent IdP will not (or should not) have information specific to ODL. This is especially true for roles, only ODL should know what the roles are and which identities possess those roles. [1]

 

>> From a third-party IdP, the incoming assertion is in the form of Map<String, Object> which is a collection of Servlet attributes and HTTP headers, which ODL will not understand.  In order to normalize this into an ODL “Claim” object that ODL can understand, an implementation of the ClaimAuth interface needs to transform the external claim into the ODL Claim object.  This transformation responsibility includes figuring out what roles user Joe has in what domain under ODL, or may be Joe is actually Bob in ODL.  The Authentication object is simply meant to represent the authentication context to be exposed to the service layer and includes an expiration.

 

Perhaps I've misread the code (please correct me) but it looks as if ClaimAuthFilter via the ClaimAuth.transform() method is supposed to map from an IdP identity assertion to a Claim object. What is confusing me is how or why would an external authn assertion know anything about the ODL roles in order to populate the roles in the Claim object? [2]

 

It seems to me there needs to be a separate mapping stage which maps from an identity assertion to ODL specific information such as tenant and roles. As an example you might want to look at how Keystone handles the federated case (https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md).

In the Keystone federation architecture one binds an (IdP, protocol) 2-tuple to a mapping which maps from IdP attributes to those used internally (i.e. groups, roles, etc.)

 

Going back to the code and the sequence diagrams shouldn't there be an IdentityClaim (does not yet exist) which is passed to a mapping endpoint (does not yet exist) which returns a Claim instead of the ClaimAuthFilter attempting to assign roles and return a Claim?

 

>> You are correct that the ClaimAuth::transform() maps the identity assertion into a Claim object.  While an external AuthN assertion does not know anything about ODL roles, the specific ClaimAuth implementation should know how to extract the external AuthN assertion information and any additional attributes needed to map that particular IdP protocol onto ODL roles/domain.  Sure, it could use a mapping service like you mentioned underneath the hood.  We could even have a generic mapping service like Keystone (thanks for the link, BTW), but to keep it simple for Helium, I am thinking we can just have a mapping service specific to SSSD, since our goal is to support SSSD, unless someone has the bandwidth to implement a generic mapping service/API—which I would be a fan of!

 

Also, I'm not sure why we have the DirectAuth case as a special case code path and flow. Couldn't the code be simplified if DirectAuth was an instance of the federated case? Here the internal DirecAuth "toy" IdP only does username/password authn and the roles are provided by a mapping? Fewer code paths usually means more robust code.

 

>> The internal IdM provides 2 main functions:  authorization (what roles does this user have in what domain?) and identity assertion (is this the user he claims to be with the given credentials?).  Direct AuthN involves both functions of the internal IdM, while the federated case involves only the first one.  Hence, we have 2 separate interfaces to call out these differences.  As you can tell, I am a fan of using separate Java interfaces to enforce/express contracts J.

 

I'm sure I have a slew of misunderstandings about how the actually code works :-) Feel free to set me straight.

 

Thanks again for the great code and excellent diagrams!

 

John

 

 

[1] Allowing an IdP to attach a role to an identity is a security concern. You may trust an IdP to authenticate a user but do you really want to trust that IdP to also claim that user has the admin role in your service? It may be case that you trust *some* IdP's to assign roles but that should be configurable and off by default. I suspect the DirectAuth case is one such example (correct?)

 

[2] It almost looks as if the authz processing is supposed to happen in

TokenEndpoint.createAccessToken() where the else clause says

 

// TODO: Support authorization code later...

 

but if the claim filters are setting the roles (which is my definition of authz) then what authorization code is going to execute here?

--

John


Re: authn vs. authz

John Dennis
 

On 06/16/2014 07:49 PM, Nguyen, Liem Manh wrote:

Hmm... for some reason my email client (Thunderbird) is having trouble
quoting your message in my reply (your text is a single long line that
Thunderbird wants to truncate) so I'm going to do some manual cut-n-paste.


You are correct that the ClaimAuth::transform() maps the identity
assertion into a Claim object. While an external AuthN assertion
does not know anything about ODL roles, the specific ClaimAuth
implementation should know how to extract the external AuthN
assertion information and any additional attributes needed to map
that particular IdP protocol onto ODL roles/domain. Sure, it could
use a mapping service like you mentioned underneath the hood. We
could even have a generic mapping service like Keystone (thanks for
the link, BTW), but to keep it simple for Helium, I am thinking we
can just have a mapping service specific to SSSD, since our goal is
to support SSSD, unless someone has the bandwidth to implement a
generic mapping service/API—which I would be a fan of!
OK, but here is my concern. The ClaimAuth filter is Java code, if I'm
understanding you correctly you're suggesting hardcoding business logic
of how to map external IdP properties into ODL properties. I don't see
how hardcoding that logic is viable.

Suppose the logic is bob@bigcorp.com is assigned the admin role. What
happens when Bob leaves or Sally is added as an admin? Do we have to
edit the Java filter code?

It seems to me the ClaimAuth filter has to rely on some loadable mapping
resource. But once you have the mapping support the game changes, see
below ...

The internal IdM provides 2 main functions: authorization (what
roles does this user have in what domain?) and identity assertion (is
this the user he claims to be with the given credentials?). Direct
AuthN involves both functions of the internal IdM, while the
federated case involves only the first one. Hence, we have 2
separate interfaces to call out these differences. As you can tell,
I am a fan of using separate Java interfaces to enforce/express
contracts J.
If you have a IdM -> ODL mapping facility then you don't need 2 distinct
implementations. The direct auth case is an instance of an external IdM
and you've eliminated a significant amount of code to author and verify
is correct.


--
John


Re: authn vs. authz

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi John,

I don't suggest hard-coding mapping logics... It should be some sort of JSON mapping file; there just won't be any API for it, unless someone has the bandwidth. For user/role assignment, we use the internal IdM APIs--Peter perhaps can go through that with us at the next presentation.

The direct auth case is an instance of an external IdM
Perhaps, we have a mix-up of words here... What I mean by direct auth is that there is no external IdP (to distinguish from federation which means external IdP).

Liem

-----Original Message-----
From: John Dennis [mailto:jdennis@redhat.com]
Sent: Tuesday, June 17, 2014 7:15 AM
To: Nguyen, Liem Manh; Abhishek Kumar; 'Arash Eghtesadi'; Lakshman Mukkamalla; Lenrow, Dave; Mellquist, Peter; Wojciech Dec; aaa-dev@lists.opendaylight.org; Nathan Kinder
Subject: Re: authn vs. authz

On 06/16/2014 07:49 PM, Nguyen, Liem Manh wrote:

Hmm... for some reason my email client (Thunderbird) is having trouble quoting your message in my reply (your text is a single long line that Thunderbird wants to truncate) so I'm going to do some manual cut-n-paste.


You are correct that the ClaimAuth::transform() maps the identity
assertion into a Claim object. While an external AuthN assertion does
not know anything about ODL roles, the specific ClaimAuth
implementation should know how to extract the external AuthN assertion
information and any additional attributes needed to map that
particular IdP protocol onto ODL roles/domain. Sure, it could use a
mapping service like you mentioned underneath the hood. We could even
have a generic mapping service like Keystone (thanks for the link,
BTW), but to keep it simple for Helium, I am thinking we can just have
a mapping service specific to SSSD, since our goal is to support SSSD,
unless someone has the bandwidth to implement a generic mapping
service/API-which I would be a fan of!
OK, but here is my concern. The ClaimAuth filter is Java code, if I'm understanding you correctly you're suggesting hardcoding business logic of how to map external IdP properties into ODL properties. I don't see how hardcoding that logic is viable.

Suppose the logic is bob@bigcorp.com is assigned the admin role. What happens when Bob leaves or Sally is added as an admin? Do we have to edit the Java filter code?

It seems to me the ClaimAuth filter has to rely on some loadable mapping resource. But once you have the mapping support the game changes, see below ...

The internal IdM provides 2 main functions: authorization (what roles
does this user have in what domain?) and identity assertion (is this
the user he claims to be with the given credentials?). Direct AuthN
involves both functions of the internal IdM, while the federated case
involves only the first one. Hence, we have 2 separate interfaces to
call out these differences. As you can tell, I am a fan of using
separate Java interfaces to enforce/express contracts J.
If you have a IdM -> ODL mapping facility then you don't need 2 distinct implementations. The direct auth case is an instance of an external IdM and you've eliminated a significant amount of code to author and verify is correct.


--
John


I cannot get on WebEx today...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

My laptop is down and I cannot get WebEx to work correctly on my Ubuntu box….  Let’s meet via #opendaylight-aaa today… sorry, guys.

 

Liem


[packetcable] Beginning the RV discussion for Helium

Ryan Moats <rmoats@...>
 

First, apologies for the major email blast, but pretty much everybody gets covered by this one...

Second, apologies if I missed any projects that declared intent to be part of helium - I'm not 100% sure I have the ODL-SDNi folks and several other projects really should update their project pages (hint hint hint).  In addition, I'm pretty sure I've missed the southbound to OC, reservation, and toolkit folks, because I don't see a mailing list for them anywhere, nor do I see information about a topic to use on dev on any of their wiki pages

Third, not to call out the reservation project further, but I looked at the project wiki page and I have *no* clue how/where reservation fits, so this project isn't currently part of this discussion.  Consider this a major hint to help me help you...

================

During last week's TSC call, I took the action item of beginning the RV discussion for Helium.  After spending the weekend looking at the twenty-five projects that have declared their intent to participate, what made the most sense to me as a starting point was to propose the following five RVs:

1. A Minimal edition, which is *NOT* guaranteed to work out of the box, but provides the base framework for research projects.
2. A Base edition, which is intended to work out of the box and so has most of the SB plug-ins
3. An SDN edition, which is intended to work in various SDN environments
4. An Intent edition, which is intended to work in situations where "intent is being managed"
5. A Full edition, which is basically the kitchen sink.

The buildup in my mind is

Minimal --- Base ---(split)-- SDN/Intent --(combine)-- Full

This draft list can be found on the Helium Release Plan page at https://wiki.opendaylight.org/view/Simultaneous_Release:Helium_Release_Plan#Proposed_Release_Vehicles where each entry is a link that will take you to a one-line description and an image showing what projects are part of that RV.

I'm going to ask that rather than reply to the entire distribution list (because it is almost the entire ODL community), that folks reply to tsc@... with comments and suggestions...

Thanks, and let the comments begin.

1 - 20 of 1823