1. Topics
  2. [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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

Regards,

Ryan

[0] https://wiki.opendaylight.org/view/TSC:Meeting#Agenda

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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

[0] https://wiki.opendaylight.org/view/TSC:Meeting#Agenda

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

[0] https://en.wikipedia.org/wiki/OpenID_Connect
[1] https://wiki.opendaylight.org/view/AAA:IP_Based_Authz

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
1 - 9 of 9