Date   

Re: Problems using Idmlight

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

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

 

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
 

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.

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. 



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

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

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


ODL - Weekly AAA Project meeting

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

When: Thursday, October 30, 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.    


RESTCONF API and AAA

xingjun chu
 

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

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
 

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

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
 

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
 

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

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
 

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

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

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

Nguyen, Liem Manh <liem_m_nguyen@...>
 

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


Re: CORS preflight in Helium requires basic authentication

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

I think only testing is needed. -:)

Thanks

George

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

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

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


AAA AuthZ presentation

Nguyen, Liem Manh <liem_m_nguyen@...>
 

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