This group is locked. No changes can be made to the group while it is locked.
|
[release] Autorelease sodium-mvn35-openjdk11 failed to build aaa-docs from aaa
Jenkins <jenkins-dontreply@...>
Attention aaa-devs,
Autorelease sodium-mvn35-openjdk11 failed to build aaa-docs from aaa in build 157. Attached is a snippet of the error message related to the failure that we were able to automatically parse as well as console logs. Console Logs: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-sodium-mvn35-openjdk11/157 Jenkins Build: https://jenkins.opendaylight.org/releng/job/autorelease-release-sodium-mvn35-openjdk11/157/ Please review and provide an ETA on when a fix will be available. Thanks, ODL releng/autorelease team
|
|
|
|
[release] Autorelease sodium-mvn35-openjdk11 failed to build aaa-docs from aaa
Jenkins <jenkins-dontreply@...>
Attention aaa-devs,
Autorelease sodium-mvn35-openjdk11 failed to build aaa-docs from aaa in build 156. Attached is a snippet of the error message related to the failure that we were able to automatically parse as well as console logs. Console Logs: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-sodium-mvn35-openjdk11/156 Jenkins Build: https://jenkins.opendaylight.org/releng/job/autorelease-release-sodium-mvn35-openjdk11/156/ Please review and provide an ETA on when a fix will be available. Thanks, ODL releng/autorelease team
|
|
|
|
2019.06.04 Kernel Projects weekly meeting minutes
Robert Varga
Hello,
the minutes for this meeting are available at: [04/06/2019 18:26:34] <odl_meetbot> Meeting ended Tue Jun 4 16:26:33 2019 UTC. Information about MeetBot at http://ci.openstack.org/meetbot.html . (v 0.1.4)Regards, Robert
|
|
|
|
Re: [release] Removal of IdP component from AAA
Daniel De La Rosa <ddelarosa@...>
On Sat, Jun 1, 2019 at 2:13 PM Robert Varga <nite@...> wrote: On 22/03/2019 22:30, Daniel De La Rosa wrote: Hello Robert We are still working with our customers on trying to determine the impact. The security team hasn’t been very responsive but we will try again and let you all know. Thanks
|
|
|
|
Re: [release] Removal of IdP component from AAA
Robert Varga
On 22/03/2019 22:30, Daniel De La Rosa wrote:
Robert, thank you for the details. Abhijit, i think we still need toHello Daniel, any update on the impact for your customers? Thanks, Robert
|
|
|
|
2019.05.28 Kernel Projects weekly meeting minutes
Robert Varga
Hello,
the minutes for this meeting are available at: [28/05/2019 18:37:44] <odl_meetbot> Meeting ended Tue May 28 16:37:43 2019 UTC. Information about MeetBot at http://ci.openstack.org/meetbot.html . (v 0.1.4)Regards, Robert
|
|
|
|
2019.05.21 Kernel Projects weekly meeting minutes
Robert Varga
Hello,
the minutes for this meeting are available at: [21/05/2019 18:53:56] <odl_meetbot> Meeting ended Tue May 21 16:53:55 2019 UTC. Information about MeetBot at http://ci.openstack.org/meetbot.html . (v 0.1.4)Sorry I have missed sending some of these out :( You can find the previous ones at http://meetings.opendaylight.org/opendaylight-meeting/2019/kernel_projects_call/ Regards, Robert
|
|
|
|
RPC name typo
Luis Gomez
Hi aaa devs,
I just realized there is a typo in 3 RPC names (s/certifcate/certificate/): This is very obvious and I guess nobody is really using these RPCs, otherwise we would have heard about this before. Anyway, my question is how do you recommend to fix this: - Just repair the typo in master. - Add RPC with right name and remove wrong name after 1 release or 2. BR/Luis
|
|
|
|
Authorization in MD-SAL RPCs
Ioakeim Samaras
Hi,
is it possible to define authorization policies on MD-SAL RPCs based on an input field? For example, I want to define policies on salflow service's 'add-flow' RPC which will restrict this RPC for specific users based on the provided node-id. I know that I can use MD-SAL datastore read/write transactions for this purpose and define policies using resource URL pattern, but I want to achieve it using the aforementioned RPC. Thank you in advance. -- Dr. Ioakeim K. Samaras Ph.D. in Electrical and Computer Engineering Intracom-Telecom, Software Development Center, Thessaloniki, Greece Industrial Systems Institute, Greece E-mail : iosam@... samaras@...
|
|
|
|
Re: [release] Removal of IdP component from AAA
Abhijit Kumbhare <abhijitkoss@...>
OK.
On Fri, Mar 22, 2019 at 2:30 PM Daniel De La Rosa <ddelarosa@...> wrote:
|
|
|
|
Re: [release] Removal of IdP component from AAA
Daniel De La Rosa <ddelarosa@...>
Robert, thank you for the details. Abhijit, i think we still need to discuss the details during our next TSC meeting since it sounds like there will be major impact for our customers Thanks
On Fri, Mar 22, 2019 at 2:12 PM Abhijit Kumbhare <abhijitkoss@...> wrote:
--
|
|
|
|
Re: [release] Removal of IdP component from AAA
Abhijit Kumbhare <abhijitkoss@...>
After Robert's explanation - do you still need it to be on the TSC agenda, Daniel (and maybe Luis)?
On Fri, Mar 22, 2019 at 2:03 PM Robert Varga <nite@...> wrote: On 21/03/2019 18:07, Luis Gomez wrote:
|
|
|
|
Re: [release] Removal of IdP component from AAA
Abhijit Kumbhare <abhijitkoss@...>
Sure.
On Fri, Mar 22, 2019 at 1:01 PM Daniel De La Rosa <ddelarosa@...> wrote:
|
|
|
|
Re: Removal of IdP component from AAA
Robert Varga
On 21/03/2019 18:07, Luis Gomez wrote:
Hi Robert,Well, I am just a caretaker trying to get things moving forward. From what I remember, user credentials should not be affected, as that goes through Shiro, which is a separate thing. I would suspect that token authentication would be affected, but I do not know the deployment details. Please note this not something new, Ryan has made a call out here: https://lists.opendaylight.org/pipermail/aaa-dev/2018-February/001606.html and there is a tracker to replace Oltu here: https://jira.opendaylight.org/browse/AAA-162. Based on the conversation we have had on this when he was still around, his assessment was that the feature is not useful in practice. I do not claim authority over this matter, nor do I claim Ryan's assessment is correct. Unfortunately, status quo in this project is simply untenable for the following reasons: 1) JIRA has not been scrubbed for a year. When I scrubbed it, we immediately got a fix from Richard Kosegi for AAA-174. That issue has been sitting there for 10 months and it was fixed in about 24 hours. 2) there are a few long-standing issues filed, which require fixing in Oltu. That is just not going to happen in upstream. 3) it is a core project, on which we rely for our security. We just cannot afford it being a security hazard. 4) org.json/json dependency, which is coming from Oltu is a real licensing concern, from what I understood from the conversations we had (even at the TSC call) around https://jira.opendaylight.org/browse/ODLPARENT-36 That is why I merged the change early in the dev cycle and announced it very widely, so that there is plenty of time to determine impacts and discuss alternatives. The simplest way to determine it is, and I am kindly asking you to, grab the latest Karaf distro and test out the functionality you expect to work. If it turns out that there are stakeholders who are affected, I think the proper course is for them (or their proxies) to come forward and take ownership of the feature: - it is mere 800LOC of code that got removed - there are at least 3 bugs filed against token auth - there are alternative libraries: https://oauth.net/code/java/ Thanks, Robert
|
|
|
|
Re: [release] Removal of IdP component from AAA
Daniel De La Rosa <ddelarosa@...>
Hello Robert and all Our customers are also asking about the impact of this IdP removal with respect to their use of token authentication so @Abhijit Kumbhare can we add this topic to the next TSC meeting? Thanks
On Thu, Mar 21, 2019 at 10:07 AM Luis Gomez <ecelgp@...> wrote: Hi Robert, --
|
|
|
|
Re: Using AAA for securing REST service
Tom Pantelis
On Thu, Mar 21, 2019 at 7:28 PM Andrej Záň <andrej.zan@...> wrote:
The web.xml mechanism was removed in Fluorine in lieu of instantiating the web app and securing it programmatically (via blueprint). For an example, check out https://github.com/opendaylight/netconf/blob/master/netconf/yanglib/src/main/resources/OSGI-INF/blueprint/yanglib.xml (org.opendaylight.yanglib.impl.WebInitializer).
|
|
|
|
Using AAA for securing REST service
Andrej Záň <andrej.zan@...>
Hello everybody,
Can somebody please tell me, how to secure our REST application with AAA? We have it done for Oxygen release, but it is not working for Fluorine SR1. What's more, documentation [0] does not help either, since it contains classes, which no more exists. So my question is, what should we have in our web.xml file? In particullar I don't know how to configure this part
<context-param>
Thanks in advance
S pozdravom Andrej Záň
[0] https://github.com/opendaylight/aaa/blob/stable/fluorine/docs/dev-guide.rst#how-application-developers-can-leverage-aaa-to-provide-servlet-security
|
|
|
|
Re: Removal of IdP component from AAA
Luis Gomez
Hi Robert,
toggle quoted messageShow quoted text
Can you please explain the impact of this? e.g. can we for instance change the default user admin/admin or use token authentication after this change? BR/Luis
On Mar 21, 2019, at 4:50 AM, Robert Varga <nite@...> wrote:
|
|
|
|
Removal of IdP component from AAA
Robert Varga
Hello everyone,
as part of keeping OpenDaylight infrastructure secure and relevant, we will be removing OAuth2 Identity Provider component from the AAA project. There are three technical drivers behind this decision: 1) current implementation is based on Apache Oltu, which has been terminated on March 21st, 2018 and moved to Attic: https://attic.apache.org/projects/oltu.html 2) Oltu depends on org.json/json, which has a problematic license (https://www.json.org/license.html) 3) we do not strive to be an IdP, as there are plenty solutions available out there. The details are in the tracker issue, https://jira.opendaylight.org/browse/AAA-173, and in the removal patch, https://git.opendaylight.org/gerrit/72022. Should there be interest in having this functionality present, we will gladly accept an alternative implementation, provided it comes with at least a minimal commitment to support it. Regards, Robert
|
|
|
|
Re: [OpenDaylight TSC] TSC Vote on Robert Varga as AAA committer
Abhijit Kumbhare <abhijitkoss@...>
Great, thanks!
On Tue, Mar 19, 2019 at 12:07 PM Robert Varga <nite@...> wrote: On 19/03/2019 17:13, Abhijit Kumbhare wrote:
|
|
|