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

Re: Problems using Idmlight

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

#181

Maybe have the readme/release notes reference API spreadsheet? And not duplicate it since we will likely enhance APIs and better to have a single source.

Peter.

From: Nguyen, Liem Manh
Sent: Friday, October 17, 2014 8:41 AM
To: Wojciech Dec
Cc: aaa-dev@...; Mellquist, Peter
Subject: Re: Problems using Idmlight

I will add that in… Thanks for spotting it.

Liem

From: Wojciech Dec <wdec.ietf@...>
Date: Friday, October 17, 2014 at 12:07 AM
To: Liem Nguyen <liem_m_nguyen@...>
Cc: "aaa-dev@..." <aaa-dev@...>, "Mellquist, Peter" <peter.mellquist@...>
Subject: Re: Problems using Idmlight

It's not in the readme, and easy to miss in the release notes (as I did).

-Wojciech

Show quoted text

On 16 October 2014 22:28, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Cool. The REST API spreadsheet (google doc) does have the “auth” in there… What documentation did you see that does not have the auth?

Thanks,

Liem

From: Wojciech Dec <wdec.ietf@...>
Date: Thursday, October 16, 2014 at 12:07 PM

To: Liem Nguyen <liem_m_nguyen@...>
Cc: "aaa-dev@..." <aaa-dev@...>, "Mellquist, Peter" <peter.mellquist@...>
Subject: Re: Problems using Idmlight

Ok, that solved it. Thanks. My bad for not looking in the pom, but I think we need to document this as the Idmlight API endpoints we've been showing do not have "auth" in them.

-Wojciech.

On 16 October 2014 20:39, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Ahh… The URL needs an “auth” in the path:

curl -si http://localhost:8282/auth/v1/domains

HTTP/1.1 200 OK

Content-Type: application/json

Transfer-Encoding: chunked

Server: Jetty(8.1.14.v20131031)

{"domains":[{"domainid":1,"name":"sdn","description":"default odl sdn domain","enabled":true}]}

Sorry, I did not look at your request carefully…

Regards,

Liem

From: Wojciech Dec <wdec.ietf@...>
Date: Thursday, October 16, 2014 at 10:29 AM
To: Liem Nguyen <liem_m_nguyen@...>
Cc: "aaa-dev@..." <aaa-dev@...>, "Mellquist, Peter" <peter.mellquist@...>
Subject: Re: Problems using Idmlight

Hi Liem,

yes, but as I mentioned I did follow the release notes and added the jetty config... Note that the curl shows that 8282 is active, but nothing is found.

Is there some order/extra steps needed in the jetty config?

On 16 October 2014 18:55, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Wojciech,

IdMLight Admin and federation endpoints are not exposed by default (for security reasons). The AAA release notes mention how to expose them (I was hoping to get that into the controller by default, but that did not make it into Helium).

Regards,

Liem

From: Wojciech Dec [mailto:wdec.ietf@...]
Sent: Thursday, October 16, 2014 9:00 AM
To: Nguyen, Liem Manh; aaa-dev@...; Mellquist, Peter
Subject: Problems using Idmlight

Hi Guys,

ok, so I wanted to take a spin and do some operations using Idmlight.

I followed the Readme and also the Release note at: https://wiki.opendaylight.org/view/AAA:Helium_Release_Notes.

Still unable to get to the API... Is there something I'm missing?

I see IdmLight proper startup in the logs:

2014-10-16 17:17:53,387 | INFO | pool-26-thread-1 | IdmLightApplication              | 238 - org.opendaylight.aaa.idmlight - 0.2.0.SNAPSHOT | starting idmlight ....
2014-10-16 17:17:53,388 | INFO | pool-26-thread-1 | IdmLightConfig                   | 238 - org.opendaylight.aaa.idmlight - 0.2.0.SNAPSHOT | DB Path                 : jdbc:sqlite:idmlight.db
2014-10-16 17:17:53,388 | INFO | pool-26-thread-1 | IdmLightConfig                   | 238 - org.opendaylight.aaa.idmlight - 0.2.0.SNAPSHOT | DB Driver               : org.sqlite.JDBC
2014-10-16 17:17:53,388 | INFO | pool-26-thread-1 | IdmLightConfig                   | 238 - org.opendaylight.aaa.idmlight - 0.2.0.SNAPSHOT | DB Valid Time Out       : 3
2014-10-16 17:17:53,388 | INFO | pool-26-thread-1 | StoreBuilder                     | 238 - org.opendaylight.aaa.idmlight - 0.2.0.SNAPSHOT | creating idmlight db

But no luck with curl...

dhcp-10-61-107-79:controller$ curl -X GET -k -s -v http://127.0.0.1:8282/v1/domains
* About to connect() to 127.0.0.1 port 8282 (#0)
*   Trying 127.0.0.1...
* Adding handle: conn: 0x7f9079804400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9079804400) send_pipe: 1, recv_pipe: 0
* Connected to 127.0.0.1 (127.0.0.1) port 8282 (#0)
> GET /v1/domains HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 127.0.0.1:8282
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 1277
* Server Jetty(8.1.14.v20131031) is not blacklisted
< Server: Jetty(8.1.14.v20131031)
<
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 404 Not Found</title>
</head>
<body>
<h2>HTTP ERROR: 404</h2>
<p>Problem accessing /v1/domains. Reason:
<pre>    Not Found</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>



</body>
</html>
* Connection #0 to host 127.0.0.1 left intact

dhcp-10-61-107-79:controller $ curl -X GET -k -s -v http://127.0.0.1:8282/hello
* About to connect() to 127.0.0.1 port 8282 (#0)
*   Trying 127.0.0.1...
* Adding handle: conn: 0x7fc3fb004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fc3fb004400) send_pipe: 1, recv_pipe: 0
* Connected to 127.0.0.1 (127.0.0.1) port 8282 (#0)
> GET /hello HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 127.0.0.1:8282
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Type: text/html;charset=ISO-8859-1
< Content-Length: 1272
* Server Jetty(8.1.14.v20131031) is not blacklisted
< Server: Jetty(8.1.14.v20131031)
<
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 404 Not Found</title>
</head>
<body>
<h2>HTTP ERROR: 404</h2>
<p>Problem accessing /hello. Reason:
<pre>    Not Found</pre></p>
<hr /><i><small>Powered by Jetty://</small></i>



</body>
</html>
* Connection #0 to host 127.0.0.1 left intact

Thoughts?

Re: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

Wojciech Dec

#182

This use-case appears to fall in line with the scope that we have set for the AAA Authz component, and at least conceptually have been designing for. It appears to be UC-3 in the Authz "breakdown" below. We're currently set on delivering on UC-1 via the common AuthZ service. A few (unsolved) design challenges, in the area of RPC broker, YANG augmentations and RPC routing, remain to get to UC-2 and UC-3, at least with the design we've been thinking of.. For those interested, read-on below...

Inline images 1

The challenge, as we currently see it, concerns of course data-domain-knowledge and scalability of the AuthZ engine, i.e. it appears to be an problematic to expect a common AuthZ service to have the insight to determine data-level decisions. Generalizing from the use-case present earlier on the thread, whether a N+1th instance of "foo" should be created by anyone, or whether a value of M for attribute "bar" is allowed to be set by user Baz, does require additional understanding of the data, with the application owning/handling that data ultimately being the better place to perform authorization, rather than a general AuthZ service engine.

For this purpose we're conceptually thinking of having apps augment the basic AuthZ RPC model, which would allow a sort of "chain of responsibility" to be installed, ie the general AuthZ service delivers basic authorization (UC1), possibly also UC2, but data-specific authorization policies, UC-3, would then result in an AuthZ RPC to the owner-app just for the data-domain insight.

At least one challenge with this approach is that the AuthZ component becomes an AuthZ RPC broker, of a kind, and possibly should have sole rights to be an AuthZ RPC broker. An alternative would be to have apps, register their specifically extended AuthZ RPC but delegate the basic AuthZ evaluation to the AuthZ service.

Anyway, before we go on, would be interested in the views of the community re the above, or any alternatives we should consider.

Regards,

Wojciech.

Show quoted text

On 16 October 2014 22:53, Colin Dixon <colin@...> wrote:

Good to know. In that case, maybe we should look at how AAA does it with their custom DataBroker to see how hard it would be to build an extensible DataBroker that allows for validation to be inserted.

--Colin

On Thu, Oct 16, 2014 at 3:49 PM, Reinaldo Penno <rapenno@...> wrote:
Applications could take care of specific constrains through DataCommit handler if it worked, but it does not. Been there, done that, no success, opened bug.

Discussed in the design forum with some colleagues, seems day 0 bug, quite entrenched.

https://bugs.opendaylight.org/show_bug.cgi?id=1435

From: Colin Dixon <colin@...>
Date: Thursday, October 16, 2014 at 1:26 PM
To: Reinaldo Penno <rapenno@...>
Cc: Devin Avery <davery@...>, "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>, "Thomas D. Nadeau" <tnadeau@...>, "controller-dev@..." <controller-dev@...>, "yangtools-dev@..." <yangtools-dev@...>

Subject: Re: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

Don't we have a notion of a commit handler which could be used to do just what Devin is asking for, that is provide application-level verification of a transaction before allowing it to succeed. It's described here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Binding-Independent_Components#Registration_of_Data_Commit_Handlers

Reinaldo, I think we should definitely support the basic constraint checking, but there will nearly always be application-level concerns which can't be expressed there, so figuring out if we have hooks to do that and how seems useful.

--Colin

On Thu, Oct 16, 2014 at 10:10 AM, Reinaldo Penno <rapenno@...> wrote:
Shouldn’t we support basic constraint checking first? must, when , min-elements, leafref, etc are not supported, let alone more elaborate stuff.

From: Devin Avery <davery@...>
Date: Thursday, October 16, 2014 at 8:07 AM
To: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>, "Thomas D. Nadeau" <tnadeau@...>
Cc: "controller-dev@..." <controller-dev@...>, "yangtools-dev@..." <yangtools-dev@...>

Subject: Re: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

The use case I am looking at is basically applying additional constraints imposed by a given implementation.

I.e., only allow this write when it doesn’t violate a given rule etc.

I am sure there is a generic solution we can create (perhaps something with policies etc), but for now I just need to be able to hardcode some java that validates the incoming change before it is committed.

Does that help?

Devin

From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Date: Thursday, October 16, 2014 at 10:32 AM
To: Tom Nadeau <tnadeau@...>
Cc: Devin Avery <davery@...>, "controller-dev@..." <controller-dev@...>, "yangtools-dev@..." <yangtools-dev@...>
Subject: RE: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

Hi,
I am trying to pinpoint your use case, because semantic validation is missing,
But some model-driven validation could be introduced in „MD-SAL“
if it is possible to model it YANG.

Are this range constraints introduced by separate model or could be express in original
YANG model or this are additional constraints imposed by implementation (which
are hard to model (when statements, must statements)?

Tony

From: Thomas D. Nadeau [mailto:tnadeau@...]
Sent: Thursday, October 16, 2014 4:21 PM
To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Cc: Devin Avery; controller-dev@...; yangtools-dev@...
Subject: Re: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

More like additional constraints beyond what appear in the syntax of the yang model in question. For example, if I have an object defined as an Integer32, but I want to constrain it to values in the range of {1-34}. It would be great to have an automatic/programmatic way of doing this say with an augmenting Yang model or something rather than having to hand-code these constraints.

--Tom

Hi Devin,
Could you be more specific what kind of validation you mean?

E.g. AAA does that by injecting DataBroker into Restconf – which does authentification
Enforcement.

Or you mean constraint validation?

Tony

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Devin Avery
Sent: Thursday, October 16, 2014 3:03 PM
To: controller-dev@...; yangtools-dev@...
Subject: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

Hi ALL -

Is there a way to intercept a write to rest conf / MD-SAL before the data is persisted to essentially provide additional (hardcoded) validation the contents beyond what is capable in restconf/md-sal today?

Thank you!

Devin
_______________________________________________
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

Content collaboration question for opendaylight.org

James Duggan <james@...>

#183

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

AAA Lithium planning

Nguyen, Liem Manh <liem_m_nguyen@...>

#184

When: Friday, October 24, 2014 9:00 AM-10:00 AM. (UTC-08:00) Pacific Time (US & Canada)
Where: Hangout

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

Hi guys,

I just want to get together briefly and discuss our plan for Lithium.  I have created a new Trello planner for the sake of discussion here:

https://trello.com/b/9gVlPYM9/opendaylight-aaa-lithium

We will be using our normal Hangout session:

https://plus.google.com/hangouts/_/event/cqpjp7haq1vps00g6sco21ac4a8

Thanks,
Liem

Calendar

ODL - Weekly AAA Project meeting

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

#185

When: Thursday, October 30, 2014 6:00 PM-7:00 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

RESTCONF API and AAA

xingjun chu

#186

HI,

Is RESTCONF integrated with AAA module for authN & authZ?

Thanks

Xingjun

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of James Duggan
Sent: Thursday, October 23, 2014 6:09 AM
To: aaa-dev@...
Subject: [Aaa-dev] Content collaboration question for opendaylight.org

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

Re: RESTCONF API and AAA

Nguyen, Liem Manh <liem_m_nguyen@...>

#187

Yes, it is. However, I believe it is using the Basic Auth feature of AAA, and not token-based auth yet.

Regards,

Liem

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Xingjun Chu
Sent: Tuesday, October 28, 2014 12:03 PM
To: aaa-dev@...
Subject: [Aaa-dev] RESTCONF API and AAA

HI,

Is RESTCONF integrated with AAA module for authN & authZ?

Thanks

Xingjun

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of James Duggan
Sent: Thursday, October 23, 2014 6:09 AM
To: aaa-dev@...
Subject: [Aaa-dev] Content collaboration question for opendaylight.org

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

Re: RESTCONF API and AAA

xingjun chu

#188

Is there a plan to switch to token based ?

Thanks

Xingjun

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Tuesday, October 28, 2014 4:12 PM
To: Xingjun Chu; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Yes, it is. However, I believe it is using the Basic Auth feature of AAA, and not token-based auth yet.

Regards,

Liem

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Xingjun Chu
Sent: Tuesday, October 28, 2014 12:03 PM
To: aaa-dev@...
Subject: [Aaa-dev] RESTCONF API and AAA

HI,

Is RESTCONF integrated with AAA module for authN & authZ?

Thanks

Xingjun

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of James Duggan
Sent: Thursday, October 23, 2014 6:09 AM
To: aaa-dev@...
Subject: [Aaa-dev] Content collaboration question for opendaylight.org

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

Re: RESTCONF API and AAA

Nguyen, Liem Manh <liem_m_nguyen@...>

#189

Just to clarify, RESTConf currently works both with Basic Auth and Token based auth. However, the clients to RestConf (such as ApiExplorer and dlux) are not using token-based auth. Sorry for the confusion.

Liem

From: Xingjun Chu [mailto:Xingjun.Chu@...]
Sent: Tuesday, October 28, 2014 1:18 PM
To: Nguyen, Liem Manh; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Is there a plan to switch to token based ?

Thanks

Xingjun

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Tuesday, October 28, 2014 4:12 PM
To: Xingjun Chu; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Yes, it is. However, I believe it is using the Basic Auth feature of AAA, and not token-based auth yet.

Regards,

Liem

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Xingjun Chu
Sent: Tuesday, October 28, 2014 12:03 PM
To: aaa-dev@...
Subject: [Aaa-dev] RESTCONF API and AAA

HI,

Is RESTCONF integrated with AAA module for authN & authZ?

Thanks

Xingjun

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of James Duggan
Sent: Thursday, October 23, 2014 6:09 AM
To: aaa-dev@...
Subject: [Aaa-dev] Content collaboration question for opendaylight.org

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

Re: RESTCONF API and AAA

xingjun chu

#190

Thanks Liem.

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Tuesday, October 28, 2014 4:26 PM
To: Xingjun Chu; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Just to clarify, RESTConf currently works both with Basic Auth and Token based auth. However, the clients to RestConf (such as ApiExplorer and dlux) are not using token-based auth. Sorry for the confusion.

Liem

From: Xingjun Chu [mailto:Xingjun.Chu@...]
Sent: Tuesday, October 28, 2014 1:18 PM
To: Nguyen, Liem Manh; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Is there a plan to switch to token based ?

Thanks

Xingjun

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Tuesday, October 28, 2014 4:12 PM
To: Xingjun Chu; aaa-dev@...
Subject: RE: RESTCONF API and AAA

Yes, it is. However, I believe it is using the Basic Auth feature of AAA, and not token-based auth yet.

Regards,

Liem

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Xingjun Chu
Sent: Tuesday, October 28, 2014 12:03 PM
To: aaa-dev@...
Subject: [Aaa-dev] RESTCONF API and AAA

HI,

Is RESTCONF integrated with AAA module for authN & authZ?

Thanks

Xingjun

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of James Duggan
Sent: Thursday, October 23, 2014 6:09 AM
To: aaa-dev@...
Subject: [Aaa-dev] Content collaboration question for opendaylight.org

Hello,

Apologies if you have already received this email.

I am contacting you today as I am currently working on a campaign for an online gaming provider and I was wondering if you accept any article contributions on your site opendaylight.org?

As we are always getting new campaigns it would be welcomed to establish long term working relationships with webmasters to collaborate with on future projects. If you would like further information, please feel free to contact me on this email address.

Thanks for your time,

James Duggan

Digital Outreach Agent

james@...

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

If you no longer wish to receive emails from us, please click here.
IDENT: 05612532e5817d19568fc8a5c7a601e3518a224f8d9910a95cb831ba6dacf995-d59427aab67b5713990f2b9e560438cadc7596433f64d99291c6cfe60feb65ed

CORS preflight in Helium requires basic authentication

Mike Arsenault

#191

Hello,

I’m running the controller on one machine and dlux (node server) on another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to retrieve the network topology using RESTCONF. However the controller responds with an HTTP 401 status to the preflight request (basically telling the browser that authentication is required). The controller will respond successfully if the basic authentication credentials are included in the preflight request. The CORS spec explicitly states that user credentials are NOT to be sent in the preflight request. Bug 2292 (https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened against aaa for this behavior.

Is there a workaround which allows basic authentication to work correctly with CORS?

Thank you,

-mike

Re: CORS preflight in Helium requires basic authentication

Nguyen, Liem Manh <liem_m_nguyen@...>

#192

Hi Mike,

Bug2292 was fixed by this Gerrit:  https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:  org.opendaylight.aaa.authn.cfg under Karaf’s etc directory and changing the authEnabled value to false.  Note that you can also change the value via the ConfigAdmin on Karaf’s webconsole or cli.  No restart is needed.

Regards,
Liem


From: Mike Arsenault <mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic authentication

Hello,

I’m running the controller on one machine and dlux (node server) on another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to retrieve the network topology using RESTCONF. However the controller responds with an HTTP 401 status to the preflight request (basically telling the browser that authentication is required). The controller will respond successfully if the basic authentication credentials are included in the preflight request. The CORS spec explicitly states that user credentials are NOT to be sent in the preflight request. Bug 2292 (https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened against aaa for this behavior.

Is there a workaround which allows basic authentication to work correctly with CORS?

Thank you,
-mike

Re: CORS preflight in Helium requires basic authentication

Mike Arsenault

#193

Hi Liem,

That is great news and big thanks to Harman for the fix. Will the fix be in the upcoming Helium SU 1 release?

Thanks,
-mike

Show quoted text

On Nov 5, 2014, at 4:55 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Mike,

Bug2292 was fixed by this Gerrit:  https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:  org.opendaylight.aaa.authn.cfg under Karaf’s etc directory and changing the authEnabled value to false.  Note that you can also change the value via the ConfigAdmin on Karaf’s webconsole or cli.  No restart is needed.

Regards,
Liem


From: Mike Arsenault <mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic authentication

Hello,

I’m running the controller on one machine and dlux (node server) on another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to retrieve the network topology using RESTCONF. However the controller responds with an HTTP 401 status to the preflight request (basically telling the browser that authentication is required). The controller will respond successfully if the basic authentication credentials are included in the preflight request. The CORS spec explicitly states that user credentials are NOT to be sent in the preflight request. Bug 2292 (https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened against aaa for this behavior.

Is there a workaround which allows basic authentication to work correctly with CORS?

Thank you,
-mike

Re: CORS preflight in Helium requires basic authentication

Nguyen, Liem Manh <liem_m_nguyen@...>

#194

Hi Mike,

Not sure how the timing will workŠ George, if I cherry pick this into
stable/helium today, will this make it into SU 1 in time?

Thanks,
Liem

Show quoted text

On 11/5/14, 3:10 PM, "Mike Arsenault" <mike@...> wrote:

Hi Liem,

That is great news and big thanks to Harman for the fix. Will the fix be
in the upcoming Helium SU 1 release?

Thanks,
-mike

On Nov 5, 2014, at 4:55 PM, Nguyen, Liem Manh <liem_m_nguyen@...>
wrote:

Hi Mike,

Bug2292 was fixed by this Gerrit:
https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We
will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:
org.opendaylight.aaa.authn.cfg under Karaf¹s etc directory and changing
the authEnabled value to false.  Note that you can also change the value
via the ConfigAdmin on Karaf¹s webconsole or cli.  No restart is needed.

Regards,
Liem


From: Mike Arsenault
<mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To: 
"aaa-dev@...<mailto:aaa-dev@...>"
<aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic
authentication

Hello,

I¹m running the controller on one machine and dlux (node server) on
another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to
retrieve the network topology using RESTCONF. However the controller
responds with an HTTP 401 status to the preflight request (basically
telling the browser that authentication is required). The controller
will respond successfully if the basic authentication credentials are
included in the preflight request. The CORS spec explicitly states that
user credentials are NOT to be sent in the preflight request. Bug 2292
(https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened
against aaa for this behavior.

Is there a workaround which allows basic authentication to work
correctly with CORS?

Thank you,
-mike

Re: CORS preflight in Helium requires basic authentication

George Zhao <George.Y.Zhao@...>

#196

Hi Liem,

Go ahead,  we still have three issues that need to be fixed.

Thanks

George

Sent from Huawei Mobile

"Nguyen, Liem Manh" <liem_m_nguyen@...> wrote:

Hi Mike,

Not sure how the timing will workŠ George, if I cherry pick this into
stable/helium today, will this make it into SU 1 in time?

Thanks,
Liem

Show quoted text

On 11/5/14, 3:10 PM, "Mike Arsenault" <mike@...> wrote:

Hi Liem,

That is great news and big thanks to Harman for the fix. Will the fix be
in the upcoming Helium SU 1 release?

Thanks,
-mike

On Nov 5, 2014, at 4:55 PM, Nguyen, Liem Manh <liem_m_nguyen@...>
wrote:

Hi Mike,

Bug2292 was fixed by this Gerrit:
https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We
will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:
org.opendaylight.aaa.authn.cfg under Karaf¹s etc directory and changing
the authEnabled value to false.  Note that you can also change the value
via the ConfigAdmin on Karaf¹s webconsole or cli.  No restart is needed.

Regards,
Liem


From: Mike Arsenault
<mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To:
"aaa-dev@...<mailto:aaa-dev@...>"
<aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic
authentication

Hello,

I¹m running the controller on one machine and dlux (node server) on
another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to
retrieve the network topology using RESTCONF. However the controller
responds with an HTTP 401 status to the preflight request (basically
telling the browser that authentication is required). The controller
will respond successfully if the basic authentication credentials are
included in the preflight request. The CORS spec explicitly states that
user credentials are NOT to be sent in the preflight request. Bug 2292
(https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened
against aaa for this behavior.

Is there a workaround which allows basic authentication to work
correctly with CORS?

Thank you,
-mike

Re: CORS preflight in Helium requires basic authentication

Nguyen, Liem Manh <liem_m_nguyen@...>

#195

Thanks, George.  The merge is in
https://git.opendaylight.org/gerrit/#/c/12534/.

Is there anything else I need to do for it to be part of SU 1?

Liem

Show quoted text

On 11/5/14, 4:05 PM, "George Zhao" <George.Y.Zhao@...> wrote:

Hi Liem,

Go ahead,  we still have three issues that need to be fixed.

Thanks

George

Sent from Huawei Mobile?

"Nguyen, Liem Manh" <liem_m_nguyen@...> wrote:


Hi Mike,

Not sure how the timing will workŠ George, if I cherry pick this into
stable/helium today, will this make it into SU 1 in time?

Thanks,
Liem

On 11/5/14, 3:10 PM, "Mike Arsenault" <mike@...> wrote:

Hi Liem,

That is great news and big thanks to Harman for the fix. Will the fix be
in the upcoming Helium SU 1 release?

Thanks,
-mike

On Nov 5, 2014, at 4:55 PM, Nguyen, Liem Manh <liem_m_nguyen@...>
wrote:

Hi Mike,

Bug2292 was fixed by this Gerrit:
https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We
will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:
org.opendaylight.aaa.authn.cfg under Karaf¹s etc directory and changing
the authEnabled value to false.  Note that you can also change the value
via the ConfigAdmin on Karaf¹s webconsole or cli.  No restart is needed.

Regards,
Liem


From: Mike Arsenault
<mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To:
"aaa-dev@...<mailto:aaa-dev@...>"
<aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic
authentication

Hello,

I¹m running the controller on one machine and dlux (node server) on
another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to
retrieve the network topology using RESTCONF. However the controller
responds with an HTTP 401 status to the preflight request (basically
telling the browser that authentication is required). The controller
will respond successfully if the basic authentication credentials are
included in the preflight request. The CORS spec explicitly states that
user credentials are NOT to be sent in the preflight request. Bug 2292
(https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened
against aaa for this behavior.

Is there a workaround which allows basic authentication to work
correctly with CORS?

Thank you,
-mike

Re: CORS preflight in Helium requires basic authentication

George Zhao <George.Y.Zhao@...>

#197

I think only testing is needed. -:)

Thanks

George

Show quoted text

-----Original Message-----
From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...] 
Sent: Thursday, November 06, 2014 1:19 AM
To: George Zhao
Cc: Mike Arsenault; aaa-dev@...
Subject: Re: [Aaa-dev] CORS preflight in Helium requires basic authentication

Thanks, George.  The merge is in
https://git.opendaylight.org/gerrit/#/c/12534/.

Is there anything else I need to do for it to be part of SU 1?

Liem

On 11/5/14, 4:05 PM, "George Zhao" <George.Y.Zhao@...> wrote:

Hi Liem,

Go ahead,  we still have three issues that need to be fixed.

Thanks

George

Sent from Huawei Mobile?

"Nguyen, Liem Manh" <liem_m_nguyen@...> wrote:

Hi Mike,

Not sure how the timing will workŠ George, if I cherry pick this into
stable/helium today, will this make it into SU 1 in time?

Thanks,
Liem

On 11/5/14, 3:10 PM, "Mike Arsenault" <mike@...> wrote:

Hi Liem,

That is great news and big thanks to Harman for the fix. Will the fix be
in the upcoming Helium SU 1 release?

Thanks,
-mike

On Nov 5, 2014, at 4:55 PM, Nguyen, Liem Manh <liem_m_nguyen@...>
wrote:

Hi Mike,

Bug2292 was fixed by this Gerrit:
https://git.opendaylight.org/gerrit/#/c/12433/  (Thanks, Harman!)  We
will cherry-pick this into Helium.

For now, you can turn off Auth by editing the properties file:
org.opendaylight.aaa.authn.cfg under Karaf¹s etc directory and changing
the authEnabled value to false.  Note that you can also change the value
via the ConfigAdmin on Karaf¹s webconsole or cli.  No restart is needed.

Regards,
Liem

From: Mike Arsenault
<mike@...<mailto:mike@...>>
Date: Wednesday, November 5, 2014 at 12:38 PM
To:
"aaa-dev@...<mailto:aaa-dev@...>"
<aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] CORS preflight in Helium requires basic
authentication

Hello,

I¹m running the controller on one machine and dlux (node server) on
another. The controller is configured to use basic authentication.

In such a configuration the browser uses CORS when attempting to
retrieve the network topology using RESTCONF. However the controller
responds with an HTTP 401 status to the preflight request (basically
telling the browser that authentication is required). The controller
will respond successfully if the basic authentication credentials are
included in the preflight request. The CORS spec explicitly states that
user credentials are NOT to be sent in the preflight request. Bug 2292
(https://bugs.opendaylight.org/show_bug.cgi?id=2292) was recently opened
against aaa for this behavior.

Is there a workaround which allows basic authentication to work
correctly with CORS?

Thank you,
-mike

AAA AuthZ presentation

Nguyen, Liem Manh <liem_m_nguyen@...>

#198

Hi Wojciech,

We missed you today at the standup…  So, I would like to reschedule it.  Would tomorrow at 7AM PST work for you?  If not, we can do next week.  Early PST mornings are best.

Thanks,
Liem

AAA AuthZ presentation

Nguyen, Liem Manh <liem_m_nguyen@...>

#199

When: Friday, November 07, 2014 7:00 AM-8:00 AM. (UTC-08:00) Pacific Time (US & Canada)
Where: Google Hangout

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

Wojciech will be going over our design for AAA AuthZ.

https://plus.google.com/hangouts/_/event/cqpjp7haq1vps00g6sco21ac4a8

Thanks,
Liem

Calendar

AAA AuthZ presentation

Nguyen, Liem Manh <liem_m_nguyen@...>

#200

When: Wednesday, November 12, 2014 7:00 AM-8:00 AM. (UTC-08:00) Pacific Time (US & Canada)
Where: Google Hangout

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

Rescheduling for next week...

Wojciech will be going over our design for AAA AuthZ.

https://plus.google.com/hangouts/_/event/cqpjp7haq1vps00g6sco21ac4a8

Thanks,
Liem

Calendar