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

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.

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
Join z.archive.aaa-dev@lists.opendaylight.org to automatically receive all group messages.