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

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