1. posterid:474561
  2. Messages

Re: UAA "remember last X passwords" feature

Sree Tummidi
 

Hi Dario,

I completely understand the sentiment. I did not mean to talk about deprecation in this fashion. Our intention is to do a survey with the CF community and understand the usage of UAA features first. We are planning to hold some office hours over zoom in the coming weeks as well. 

I would love to see UAA being an alternative to Enterprise Identity Providers but we have decided to not go down that path because that involves adding and maintaining features which are going beyond the CF UAA team's capacity and scope. We have decided to align UAA to the needs of OSS CF and continue to grow the capabilities in the federation and application identity space. These areas are extremely relevant for our community of developers and operators in CF. The reality we are facing is that we have limited resources and we want to work on things which yield the best results for the CF community holistically .

In conclusion, we are not looking to prioritize this feature work (more enhancements around Internal User Store) as its not aligned to the direction we want to take the product in.

Thanks,
Sree Tummidi
Sr. Manager, Product Management
Pivotal Cloud Foundry

On Tue, Dec 11, 2018 at 8:28 AM Chip Childers <cchilders@...> wrote:
On Fri, Dec 7, 2018 at 12:50 PM Dario Amiri via Lists.Cloudfoundry.Org <damiri=zuora.com@...> wrote:
Hi Sree,

This is disappointing news. There are members of the community that have come to rely on UAA as an alternative to deploying burdensome enterprise solutions. Would it be possible for you to please share more details on the justification for this course of action? Is there a higher power we can appeal this decision to?

I agree that it would be worthwhile for the community to hear more of the thought process from Sree or others in the project team. Would the project be open to PR's from interested parties (like Dario) to add smaller features that support the use case Dario is sharing? Any other folks out there want to chime in on the use case? Do you think it's valid? Do you think it's more logical to limit the scope of UAA to bridging to other ID providers?
 
If we have to fork, would the CF foundation allow us to fork under another foundation (e.g. Apache) that can help continue UAA development in a way that serves the whole community of UAA users?

The code is licensed to the world via the ASLv2, which allows forking and modifying the code as long as the license's requirements are met. Remember that keeping up with the upstream would likely be important (example would be where a vulnerability is resolved and publicly disclosed). Also remember that a license to the code is not a license to any CFF trademarks or word marks. I'm not judging the idea either way, just noting some considerations.
Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.