Date   

Re: Idmlight - Grant?

Nguyen, Liem Manh <liem_m_nguyen@...>
 

I believe that is the tertiary association between user, role, and domain.

Liem

From: Wojciech Dec <wdec.ietf@...<mailto:wdec.ietf@...>>
Date: Wednesday, October 15, 2014 at 1:26 PM
To: "Mellquist, Peter" <peter.mellquist@...<mailto:peter.mellquist@...>>, "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] Idmlight - Grant?

Hi Peter,

I was browsing through the Idmlight code and API and noticed the "Grant" model item/class, which tbh it is not clear what is it for. Could you kindly provide your insights into what is it meant for?

Regards,
Wojciech.


Re: Idmlight - Grant?

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

 

Wojciech,

 

Good question.  Looking at the code I think you are seeing the internal Grant resource but it’s not directly surfaced through the REST model? Which raises a few questions.

 

As Liem points out a ‘grant’ is a 3-way association between a user, role and domain. This allows granting a user a role for a domain. 

 

The AAA IDM REST model does *not* have a Grant resource instead it is based on the REST resources /domains/{domainId}/users/{userId}/roles where doing a POST creates a grant. See API docs https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

 

The thought did cross my mind to have an actual /grants REST resource but instead we stayed close to the Keystone way.

 

Peter.

 

 

From: Nguyen, Liem Manh
Sent: Wednesday, October 15, 2014 6:19 PM
To: Wojciech Dec; Mellquist, Peter; aaa-dev@...
Subject: Re: [Aaa-dev] Idmlight - Grant?

 

I believe that is the tertiary association between user, role, and domain.

 

Liem

 

From: Wojciech Dec <wdec.ietf@...>
Date: Wednesday, October 15, 2014 at 1:26 PM
To: "Mellquist, Peter" <peter.mellquist@...>, "aaa-dev@..." <aaa-dev@...>
Subject: [Aaa-dev] Idmlight - Grant?

 

Hi Peter,

I was browsing through the Idmlight code and API and noticed the "Grant" model item/class, which tbh it is not clear what is it for. Could you kindly provide your insights into what is it meant for?

Regards,

Wojciech.


Problems using Idmlight

Wojciech Dec
 

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?


today's meeting

Wojciech Dec
 

Hi All,

I have another meeting that I've been called into...
Wanted to to attend today's call to discuss the Lithium plan, for which I put down a few items - basic question though above all: By when do we need to complete the proposal?

Cheers,
Wojciech.


Re: Problems using Idmlight

Nguyen, Liem Manh <liem_m_nguyen@...>
 

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: Problems using Idmlight

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Just want to add some clarification… We want to expose the admin and federation endpoints on different ports than the rest of the controller REST API (e.g., RestConf).  So, for the example in the gerrit, idm admin lives on port 8282 and federation on port 8383.

 

Liem

 

From: Nguyen, Liem Manh
Sent: Thursday, October 16, 2014 9:53 AM
To: 'Wojciech Dec'; aaa-dev@...; Mellquist, Peter
Subject: RE: Problems using Idmlight

 

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: today's meeting

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Wojciech,

 

No worries…  The tentative Lithium release plan is here:

 

https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan

 

Looks like we will need to declare our intent to participate in the release by 11/6/2014.

 

Wojciech, feel free to ping me on Hangout/IRC, and I can fill you in…

 

Also..  Just a pulse check…  Is Thursdays at 9PST still good with everyone for stand-ups? 

 

Cheers,

Liem

 

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of Wojciech Dec
Sent: Thursday, October 16, 2014 9:08 AM
To: aaa-dev@...
Subject: [Aaa-dev] today's meeting

 

Hi All,

I have another meeting that I've been called into...

Wanted to to attend today's call to discuss the Lithium plan, for which I put down a few items - basic question though above all: By when do we need to complete the proposal?

Cheers,

Wojciech.


Re: Problems using Idmlight

Wojciech Dec
 

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: Idmlight - Grant?

Wojciech Dec
 

Hi Peter, Liem,

ok, so I think I can see what it is, but it's not  clear what value it provides is its current form, ie:
curl -X POST -s -H "Content-type:application/json" -d
{
    "roleid":"2",
    "description":"role grant"
}
https://<controller>/auth/v1/domains/2/users/2/roles

Has the "createGrant" method return the SQL db key as the "grant" in the response:

{
    "description": "role grant",
    "domainid": "2",
    "grantid": "2",
    "roleid": "2",
    "userid": "2"
}

When would it come to be useful?

Now that said I have a suggestion or two, for possibly changing it into something an admin would find interesting in the scope of AuthZ: user-groups.
What we're currently missing is the administrative notion of "user-groups" i.e. the ability to apply a set of authz permissions that are grouped under a role could be assigned to a set of groups, or a set of users independently of their group.

Thoughts?

Regards,
Wojciech.


On 16 October 2014 03:31, Mellquist, Peter <peter.mellquist@...> wrote:

 

Wojciech,

 

Good question.  Looking at the code I think you are seeing the internal Grant resource but it’s not directly surfaced through the REST model? Which raises a few questions.

 

As Liem points out a ‘grant’ is a 3-way association between a user, role and domain. This allows granting a user a role for a domain. 

 

The AAA IDM REST model does *not* have a Grant resource instead it is based on the REST resources /domains/{domainId}/users/{userId}/roles where doing a POST creates a grant. See API docs https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

 

The thought did cross my mind to have an actual /grants REST resource but instead we stayed close to the Keystone way.

 

Peter.

 

 

From: Nguyen, Liem Manh
Sent: Wednesday, October 15, 2014 6:19 PM
To: Wojciech Dec; Mellquist, Peter; aaa-dev@...
Subject: Re: [Aaa-dev] Idmlight - Grant?

 

I believe that is the tertiary association between user, role, and domain.

 

Liem

 

From: Wojciech Dec <wdec.ietf@...>
Date: Wednesday, October 15, 2014 at 1:26 PM
To: "Mellquist, Peter" <peter.mellquist@...>, "aaa-dev@..." <aaa-dev@...>
Subject: [Aaa-dev] Idmlight - Grant?

 

Hi Peter,

I was browsing through the Idmlight code and API and noticed the "Grant" model item/class, which tbh it is not clear what is it for. Could you kindly provide your insights into what is it meant for?

Regards,

Wojciech.



Re: Problems using Idmlight

Nguyen, Liem Manh <liem_m_nguyen@...>
 

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@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 10:29 AM
To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto:liem_m_nguyen@...>> wrote:
Hi Wojciech,

IdMLight Admin and federation endpoints are not exposed by default (for security reasons). The AAA release notes<https://wiki.opendaylight.org/view/AAA:Helium_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@...<mailto:wdec.ietf@...>]
Sent: Thursday, October 16, 2014 9:00 AM
To: Nguyen, Liem Manh; aaa-dev@...<mailto: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<http://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<http://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: Idmlight - Grant?

Nguyen, Liem Manh <liem_m_nguyen@...>
 

I will let Peter answer the grantId question, but for user group, that is something we wanted to support for Helium but decided to descope it due to lack of resources… Personally, I would like to see that implemented in Lithium. It will make it easier to manage role/permissions as well as making federation mapping easier too.

Liem

From: Wojciech Dec <wdec.ietf@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 11:39 AM
To: "Mellquist, Peter" <peter.mellquist@...<mailto:peter.mellquist@...>>
Cc: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>, "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>
Subject: Re: [Aaa-dev] Idmlight - Grant?

Hi Peter, Liem,

ok, so I think I can see what it is, but it's not clear what value it provides is its current form, ie:
curl -X POST -s -H "Content-type:application/json" -d
{
"roleid":"2",
"description":"role grant"
}
https://<controller>/auth/v1/domains/2/users/2/roles

Has the "createGrant" method return the SQL db key as the "grant" in the response:

{
"description": "role grant",
"domainid": "2",
"grantid": "2",
"roleid": "2",
"userid": "2"
}

When would it come to be useful?

Now that said I have a suggestion or two, for possibly changing it into something an admin would find interesting in the scope of AuthZ: user-groups.
What we're currently missing is the administrative notion of "user-groups" i.e. the ability to apply a set of authz permissions that are grouped under a role could be assigned to a set of groups, or a set of users independently of their group.

Thoughts?

Regards,
Wojciech.

On 16 October 2014 03:31, Mellquist, Peter <peter.mellquist@...<mailto:peter.mellquist@...>> wrote:

Wojciech,

Good question. Looking at the code I think you are seeing the internal Grant resource but it’s not directly surfaced through the REST model? Which raises a few questions.

As Liem points out a ‘grant’ is a 3-way association between a user, role and domain. This allows granting a user a role for a domain.

The AAA IDM REST model does *not* have a Grant resource instead it is based on the REST resources /domains/{domainId}/users/{userId}/roles where doing a POST creates a grant. See API docs https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0<https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit>

The thought did cross my mind to have an actual /grants REST resource but instead we stayed close to the Keystone way.

Peter.


From: Nguyen, Liem Manh
Sent: Wednesday, October 15, 2014 6:19 PM
To: Wojciech Dec; Mellquist, Peter; aaa-dev@...<mailto:aaa-dev@...>
Subject: Re: [Aaa-dev] Idmlight - Grant?

I believe that is the tertiary association between user, role, and domain.

Liem

From: Wojciech Dec <wdec.ietf@...<mailto:wdec.ietf@...>>
Date: Wednesday, October 15, 2014 at 1:26 PM
To: "Mellquist, Peter" <peter.mellquist@...<mailto:peter.mellquist@...>>, "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>
Subject: [Aaa-dev] Idmlight - Grant?

Hi Peter,
I was browsing through the Idmlight code and API and noticed the "Grant" model item/class, which tbh it is not clear what is it for. Could you kindly provide your insights into what is it meant for?
Regards,
Wojciech.


Re: Problems using Idmlight

Wojciech Dec
 

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: Problems using Idmlight

Nguyen, Liem Manh <liem_m_nguyen@...>
 

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@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 12:07 PM
To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto: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@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 10:29 AM
To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto:liem_m_nguyen@...>> wrote:
Hi Wojciech,

IdMLight Admin and federation endpoints are not exposed by default (for security reasons). The AAA release notes<https://wiki.opendaylight.org/view/AAA:Helium_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@...<mailto:wdec.ietf@...>]
Sent: Thursday, October 16, 2014 9:00 AM
To: Nguyen, Liem Manh; aaa-dev@...<mailto: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<http://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<http://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?


User Account CRUD via REST

Kinard, Andrew <akinard@...>
 

Hello Liem and friends,

We were making use of the UserManager in Hydrogen to list, create, modify, delete users in ODL. Does Helium have a similar RESTful resource?

Many thanks,

-Andrew Kinard

Sent from my iPhone.



________________________________

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.


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

Colin Dixon <colin@...>
 

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




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

Reinaldo Penno <rapenno@...>
 

Agree for application level validation. For “boilerplate” validation such as Yang must, leaf ref, etc I would like datastore to take care  of that, otherwise everybody will need to write their own Yang interpreter (or something like it) and validation methods.

From: Colin Dixon <colin@...>
Date: Thursday, October 16, 2014 at 1:53 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@...>, "aaa-dev@..." <aaa-dev@...>
Subject: Re: [controller-dev] Intercepting RestConf/MD-SAL writes to do additional verification?

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




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

Colin Dixon <colin@...>
 

I couldn't agree more.

On Thu, Oct 16, 2014 at 4:10 PM, Reinaldo Penno <rapenno@...> wrote:
Agree for application level validation. For “boilerplate” validation such as Yang must, leaf ref, etc I would like datastore to take care  of that, otherwise everybody will need to write their own Yang interpreter (or something like it) and validation methods.

From: Colin Dixon <colin@...>
Date: Thursday, October 16, 2014 at 1:53 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@...>, "aaa-dev@..." <aaa-dev@...>

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

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





Re: User Account CRUD via REST

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Andrew,

Helium does have a set of APIs (IdM) for CRUD¹ing users:

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1
wZskwWwY/edit#gid=0


These admin APIs are meant to run on a separate port for security reason;
so, you will need to add in a separate connector in your Karaf's jetty.xml
file as described in the release notes:

https://wiki.opendaylight.org/view/AAA:Helium_Release_Notes



Regards,
Liem

On 10/16/14, 1:53 PM, "Kinard, Andrew" <akinard@...> wrote:

Hello Liem and friends,

We were making use of the UserManager in Hydrogen to list, create,
modify, delete users in ODL. Does Helium have a similar RESTful resource?

Many thanks,

-Andrew Kinard

Sent from my iPhone.



________________________________

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and
proprietary material and is solely for the use of the intended recipient.
Any review, use, disclosure, distribution or copying of this transmittal
is prohibited except by or on behalf of the intended recipient. If you
have received this transmittal in error, please notify the sender and
destroy this e-mail and any attachments and all copies, whether
electronic or printed.
_______________________________________________
Aaa-dev mailing list
Aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev


Re: Problems using Idmlight

Wojciech Dec
 

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: Problems using Idmlight

Nguyen, Liem Manh <liem_m_nguyen@...>
 

I will add that in… Thanks for spotting it.

Liem

From: Wojciech Dec <wdec.ietf@...<mailto:wdec.ietf@...>>
Date: Friday, October 17, 2014 at 12:07 AM
To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto: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@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 12:07 PM

To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto: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@...<mailto:wdec.ietf@...>>
Date: Thursday, October 16, 2014 at 10:29 AM
To: Liem Nguyen <liem_m_nguyen@...<mailto:liem_m_nguyen@...>>
Cc: "aaa-dev@...<mailto:aaa-dev@...>" <aaa-dev@...<mailto:aaa-dev@...>>, "Mellquist, Peter" <peter.mellquist@...<mailto: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@...<mailto:liem_m_nguyen@...>> wrote:
Hi Wojciech,

IdMLight Admin and federation endpoints are not exposed by default (for security reasons). The AAA release notes<https://wiki.opendaylight.org/view/AAA:Helium_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@...<mailto:wdec.ietf@...>]
Sent: Thursday, October 16, 2014 9:00 AM
To: Nguyen, Liem Manh; aaa-dev@...<mailto: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<http://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<http://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?

161 - 180 of 1823