Date   

Re: ssh passwordless login to Karaf

Jamo Luhrsen <jluhrsen@...>
 

if it's possible to use a wrapper to ssh, you could try sshpass like
we do in our CSIT deployment logic:

https://git.opendaylight.org/gerrit/gitweb?p=releng/builder.git;a=blob;f=jjb/integration/integration-deploy-controller-run-test.sh;h=021161e61d6a10646aaf01618dba9d0eae810bc1;hb=fb567a578ef3dcad21d85b0e471f745fcbe9aed6#l143

JamO

On 6/13/18 6:56 AM, Ryan Goulding wrote:
Vamsi,
AAA does not control karaf's authentication; the two are configured separately.  I suggest you engage the upstream Apache Karaf community.
HTH.
Regards,
Ryan
Regards,
Ryan Goulding
On Wed, Jun 13, 2018 at 5:27 AM, A Vamsikrishna <a.vamsikrishna@ericsson.com <mailto:a.vamsikrishna@ericsson.com>> wrote:
Hi Stephen / Ryan,____
__ __
Can you please help me with the steps to perform ssh passwordless login to Karaf ?____
__ __
Thanks,____
Vamsi____
_______________________________________________
aaa-dev mailing list
aaa-dev@lists.opendaylight.org <mailto:aaa-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/aaa-dev <https://lists.opendaylight.org/mailman/listinfo/aaa-dev>
_______________________________________________
aaa-dev mailing list
aaa-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/aaa-dev


Re: ssh passwordless login to Karaf

Ryan Goulding <ryandgoulding@...>
 

Vamsi,

AAA does not control karaf's authentication; the two are configured separately.  I suggest you engage the upstream Apache Karaf community.

HTH.

Regards,
Ryan

Regards,

Ryan Goulding

On Wed, Jun 13, 2018 at 5:27 AM, A Vamsikrishna <a.vamsikrishna@...> wrote:

Hi Stephen / Ryan,

 

Can you please help me with the steps to perform ssh passwordless login to Karaf ?

 

Thanks,

Vamsi


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



ssh passwordless login to Karaf

A Vamsikrishna
 

Hi Stephen / Ryan,

 

Can you please help me with the steps to perform ssh passwordless login to Karaf ?

 

Thanks,

Vamsi


Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

Luis Gomez
 

This sounds more like my second item, what about the first or third? what kind of upstream patch requires downstream project build? or you think by just building the patch, replacing jars in distribution and running some CSIT we would catch any issue we would see when you build a downstream project?

On Jun 6, 2018, at 8:28 AM, Robert Varga <nite@hq.sk> wrote:

On 06/06/18 17:15, Luis Gomez wrote:
Couple of notes here: the "test-<project>-<feature>" framework used to trigger CSIT on a patch only works in Snapshot integrated projects (mdsal, controller, etc…) and it does not build any downstream project apart from distribution.

So this makes me wonder for this and also MRI project like odlparent, yangtools, what kind of patch verification is more useful:

- Build all downstream projects
- Build patch + distribution + run CSIT
- Build all downstream projects + run CSIT (expensive but possible)
My thinking is:
1) build patch
2) download current distribution
3) unpack
4) overwrite existing .jars (yeah, utterly ignoring versions)
5) repack
6) run CSIT

Dirty, but should be very quick & effective -- MRIs are supposed to be
ABI-backwards-compatible after all :)

This will not work with packaging changes (i.e. different set of .jars),
but that should be very very rare.

Regards,
Robert


Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

Robert Varga
 

On 06/06/18 17:15, Luis Gomez wrote:
Couple of notes here: the "test-<project>-<feature>" framework used to trigger CSIT on a patch only works in Snapshot integrated projects (mdsal, controller, etc…) and it does not build any downstream project apart from distribution.

So this makes me wonder for this and also MRI project like odlparent, yangtools, what kind of patch verification is more useful:

- Build all downstream projects
- Build patch + distribution + run CSIT
- Build all downstream projects + run CSIT (expensive but possible)
My thinking is:
1) build patch
2) download current distribution
3) unpack
4) overwrite existing .jars (yeah, utterly ignoring versions)
5) repack
6) run CSIT

Dirty, but should be very quick & effective -- MRIs are supposed to be
ABI-backwards-compatible after all :)

This will not work with packaging changes (i.e. different set of .jars),
but that should be very very rare.

Regards,
Robert


Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches

Luis Gomez
 

Couple of notes here: the "test-<project>-<feature>" framework used to trigger CSIT on a patch only works in Snapshot integrated projects (mdsal, controller, etc…) and it does not build any downstream project apart from distribution.

So this makes me wonder for this and also MRI project like odlparent, yangtools, what kind of patch verification is more useful:

- Build all downstream projects
- Build patch + distribution + run CSIT
- Build all downstream projects + run CSIT (expensive but possible)

BR/Luis

On Jun 6, 2018, at 5:16 AM, Robert Varga <nite@hq.sk> wrote:

On 05/06/18 16:28, Sam Hague wrote:
All the projects in the to: list have the ability to run genius and
netvirt csit on any patch using a gerrit comment. The job is non-voting
and only reports back status. If you do run the csit and notice a
non-success, please ping the genius and netvirt lists to look at the job
so the team can fix any issues found.

The format of the comment is:
test-<project>-<genius|netvirt|cluster-netvirt>.

For example, on a controller patch, you would add this comment to run
genius csit: test-controller-genius. This is shown in controller
patch: https://git.opendaylight.org/gerrit/#/c/72650/.

For aaa to run netvirt csit, test-aaa-netvirt.
This is awesome :) although yangtools would also need a replacement of
jars, so I am not sure how useful it is at this time :)

Thanks,
Robert

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [yangtools-dev] patch-test triggers to run csit on patches

Robert Varga
 

On 05/06/18 16:28, Sam Hague wrote:
All the projects in the to: list have the ability to run genius and
netvirt csit on any patch using a gerrit comment. The job is non-voting
and only reports back status. If you do run the csit and notice a
non-success, please ping the genius and netvirt lists to look at the job
so the team can fix any issues found.

The format of the comment is:
test-<project>-<genius|netvirt|cluster-netvirt>. 

For example, on a controller patch, you would add this comment to run
genius csit: test-controller-genius. This is shown in controller
patch: https://git.opendaylight.org/gerrit/#/c/72650/.

For aaa to run netvirt csit, test-aaa-netvirt.
This is awesome :) although yangtools would also need a replacement of
jars, so I am not sure how useful it is at this time :)

Thanks,
Robert


patch-test triggers to run csit on patches

Sam Hague <shague@...>
 

All the projects in the to: list have the ability to run genius and netvirt csit on any patch using a gerrit comment. The job is non-voting and only reports back status. If you do run the csit and notice a non-success, please ping the genius and netvirt lists to look at the job so the team can fix any issues found.

The format of the comment is: test-<project>-<genius|netvirt|cluster-netvirt>. 

For example, on a controller patch, you would add this comment to run genius csit: test-controller-genius. This is shown in controller patch: https://git.opendaylight.org/gerrit/#/c/72650/.

For aaa to run netvirt csit, test-aaa-netvirt.

Thanks, Sam


Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Abhijit Kumbhare <abhijitkoss@...>
 

Sure Ryan. 

BTW - we only keep agenda items for the current week. So you should add under the main agenda items - and not add a fresh section for a new TSC meeting (as Michael and you have done for your topics). I just corrected yours - but before that it looked very strange: 

The next TSC meeting is scheduled May 31st with the following proposed agenda:

  • Remove OLTU and AAA OAuth2 Provider

The next TSC meeting is scheduled May 24th with the following proposed agenda:

  • How to simu-merge next managed topic weather item TSC-101, when ready? RelEng? Automation? Would project accept bot commiter? Would LF host it?
  • Objections to https://git.opendaylight.org/gerrit/#/c/72168/ to skip SFT on the full autorelease to avoid false positives? Still caught by distribution and projects' verify jobs.


The next TSC meeting is scheduled May 17th, 2018 at 10:00a Pacific with the following agenda:

  • Start the Recording
  • ...
  • ...
  • Add yours either here - or under an appropriate subbullet like general topics or 

 Above yours and Michael's edits are shown above in red - but they should have been under the section shown above in blue.

On Wed, May 30, 2018 at 12:51 PM, Ryan Goulding <ryandgoulding@...> wrote:
No one responded, so I took the liberty to add this topic to the proposed agenda here [0].  Please let me know if we do not have time to discuss this.

Regards,

Ryan


On Wed, May 30, 2018 at 10:27 AM, Ryan Goulding <ryandgoulding@...> wrote:
TSC,

Can we get some clarification on this?  Or at least add it as an agenda item for the meeting tomorrow, as we didn't have time last week?

Thanks,
Ryan

On Tue, May 29, 2018 at 9:25 AM, Ryan Goulding <ryandgoulding@...> wrote:
Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.

100% agreed.  Again, this was something added long before my time, and there was probably a good reason at the time.  However, I agree that it is short-sighted to continue maintaining this in ODL.

TSC, do we need a vote on removing this functionality this release?  Or a #agreed?

Thanks,
Ryan


On Fri, May 25, 2018 at 10:51 AM, Michael Vorburger <vorburger@...> wrote:
On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

https://www.keycloak.org can be used to do this sort of thing, AFAIK.  

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.
 
Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc







_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Ryan Goulding <ryandgoulding@...>
 

No one responded, so I took the liberty to add this topic to the proposed agenda here [0].  Please let me know if we do not have time to discuss this.

On Wed, May 30, 2018 at 10:27 AM, Ryan Goulding <ryandgoulding@...> wrote:
TSC,

Can we get some clarification on this?  Or at least add it as an agenda item for the meeting tomorrow, as we didn't have time last week?

Thanks,
Ryan

On Tue, May 29, 2018 at 9:25 AM, Ryan Goulding <ryandgoulding@...> wrote:
Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.

100% agreed.  Again, this was something added long before my time, and there was probably a good reason at the time.  However, I agree that it is short-sighted to continue maintaining this in ODL.

TSC, do we need a vote on removing this functionality this release?  Or a #agreed?

Thanks,
Ryan


On Fri, May 25, 2018 at 10:51 AM, Michael Vorburger <vorburger@...> wrote:
On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

https://www.keycloak.org can be used to do this sort of thing, AFAIK.  

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.
 
Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc







Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Ryan Goulding <ryandgoulding@...>
 

TSC,

Can we get some clarification on this?  Or at least add it as an agenda item for the meeting tomorrow, as we didn't have time last week?

Thanks,
Ryan

On Tue, May 29, 2018 at 9:25 AM, Ryan Goulding <ryandgoulding@...> wrote:
Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.

100% agreed.  Again, this was something added long before my time, and there was probably a good reason at the time.  However, I agree that it is short-sighted to continue maintaining this in ODL.

TSC, do we need a vote on removing this functionality this release?  Or a #agreed?

Thanks,
Ryan


On Fri, May 25, 2018 at 10:51 AM, Michael Vorburger <vorburger@...> wrote:
On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

https://www.keycloak.org can be used to do this sort of thing, AFAIK.  

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.
 
Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc






Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Ryan Goulding <ryandgoulding@...>
 

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.

100% agreed.  Again, this was something added long before my time, and there was probably a good reason at the time.  However, I agree that it is short-sighted to continue maintaining this in ODL.

TSC, do we need a vote on removing this functionality this release?  Or a #agreed?

Thanks,
Ryan


On Fri, May 25, 2018 at 10:51 AM, Michael Vorburger <vorburger@...> wrote:
On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

https://www.keycloak.org can be used to do this sort of thing, AFAIK.  

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.
 
Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc





Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Michael Vorburger <vorburger@...>
 

On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

https://www.keycloak.org can be used to do this sort of thing, AFAIK.  

Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.
 
Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Ryan Goulding <ryandgoulding@...>
 

Any idea on what could be the alternative to oauth2 API?

Federating with an existing OpenID Connect IdP [0].  OpenID provides an authentication layer on top of the OAuth2 authorization layer.  Currently, this would need to be done by fronting ODL with a web server supporting these capabilities and locking down the jetty server to localhost only.  A similar setup is shown through [1] and is possible with other IdPs/use cases.

Regards,

Ryan


On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Tom Pantelis
 



On Thu, May 24, 2018 at 6:31 PM, Michael Vorburger <vorburger@...> wrote:
On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:

Dear TSC,


On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.


Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.


The only question then becomes execution.  There are a few options we can take:


1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.


2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.


3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.


I prefer option #3, but am open to discussion.


Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

Same here - if none of the current stakeholders in upstream ODL use it and have any objections. It's unlikely anyone uses it. While #1 follows our normal MO, if the dependency might introduce a security non-compliance and the fact that it's dead, I think that should trump the our normal MO. 

 

_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Luis Gomez
 

Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side.

BR/Luis


On May 24, 2018, at 3:31 PM, Michael Vorburger <vorburger@...> wrote:

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
Dear TSC,

On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.

Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.

The only question then becomes execution.  There are a few options we can take:

1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.

2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.

3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.

I prefer option #3, but am open to discussion.

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

Michael Vorburger <vorburger@...>
 

On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:

Dear TSC,


On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.


Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.


The only question then becomes execution.  There are a few options we can take:


1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.


2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.


3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.


I prefer option #3, but am open to discussion.


Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.


Re: Committers Please Vote

Ryan Goulding <ryandgoulding@...>
 

All existing committers have voted +1.  I will raise this to the TSC for a vote.

Thanks,

Ryan

On Thu, May 24, 2018 at 11:01 AM, Mohamed El-Serngawy <m.elserngawy@...> wrote:
+1

BR

On Thu, May 24, 2018 at 8:30 AM, Ryan Goulding <ryandgoulding@...> wrote:
+1.

Regards,

Ryan Goulding

On Thu, May 24, 2018 at 8:29 AM, Ryan Goulding <ryandgoulding@...> wrote:
Hi Folks,

I would like to nominate Tom Pantelis as a committer to AAA.  Tom has been instrumental in the adoption of the web-api, as well as many other accomplishments.  He has 25+ commits in AAA as shown here [0].  I believe his merits are clearly displayed in AAA as well as the other various projects he maintains.  Please vote +1, 0, -1.



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




--
Mohamed ElSerngawy

+1 438 993 2462


Available Approaches For Eliminating Apache OLTU Dependencies

Ryan Goulding <ryandgoulding@...>
 

Dear TSC,


On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0].  This means it is no longer maintained and there will be no new releases.  The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes.  As such, we should move away from utilizing OLTU.


Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all.  I am not entirely sure of the original motivation, since it happened long before I was involved in the project.  However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version.  I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs.


The only question then becomes execution.  There are a few options we can take:


1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency.  We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead.  For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability.


2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2].  This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3].  However, we would then need to agree to maintain this code ourselves for the release.  It would allow us to adhere to our rule to deprecate in one release and remove in the following.


3) Release Fluorine without the token HTTP service [4].  This would violate our rule to deprecate in one release and remove in the following.  It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate.  I have limited insight into how it is used by consumers.


I prefer option #3, but am open to discussion.


Thanks,

Ryan  


[0] http://mail-archives.apache.org/mod_mbox/www-announce/201804.mbox/%3CCD6C954D-F93A-473E-9B2F-60C05231D532%40apache.org%3E

[1] https://jira.opendaylight.org/projects/AAA/issues/AAA-173

[2] https://git.opendaylight.org/gerrit/#/c/72038/

[3] https://jira.opendaylight.org/browse/ODLPARENT-36

[4] https://git.opendaylight.org/gerrit/#/c/72022/



Re: Committers Please Vote

Mohamed ElSerngawy
 

+1

BR

On Thu, May 24, 2018 at 8:30 AM, Ryan Goulding <ryandgoulding@...> wrote:
+1.

Regards,

Ryan Goulding

On Thu, May 24, 2018 at 8:29 AM, Ryan Goulding <ryandgoulding@...> wrote:
Hi Folks,

I would like to nominate Tom Pantelis as a committer to AAA.  Tom has been instrumental in the adoption of the web-api, as well as many other accomplishments.  He has 25+ commits in AAA as shown here [0].  I believe his merits are clearly displayed in AAA as well as the other various projects he maintains.  Please vote +1, 0, -1.



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




--
Mohamed ElSerngawy

+1 438 993 2462

121 - 140 of 1823