1. Cf-Dev
  2. Topics

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.
Chip Childers <cchilders@...>
 

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.
Dario Amiri <damiri@...>
 

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?

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?

Regards,

Dario
Sree Tummidi
 

Hi Ryan,
Best would be to fork and add the needed features for password policy. UAA will continue to support all the federation use cases and act as an OAuth2 server

Thanks,
Sree


On Dec 7, 2018, at 8:59 AM, ryancutter@... wrote:

Thanks for the explanation, Sree.  Do you have additional information about these plans?  My organization likes using open source software for user/password, OAuth client, SSO, etc data so we'd like to see if we can make UAA continue to work for us.  We're wondering if we should consider alternatives (if so, can you recommend?).  If we want to continue to utilize UAA for these features, do we need to consider forking and building out from there?

Thanks for all your help, Ryan

ryancutter@...
 

Thanks for the explanation, Sree.  Do you have additional information about these plans?  My organization likes using open source software for user/password, OAuth client, SSO, etc data so we'd like to see if we can make UAA continue to work for us.  We're wondering if we should consider alternatives (if so, can you recommend?).  If we want to continue to utilize UAA for these features, do we need to consider forking and building out from there?

Thanks for all your help, Ryan
Sree Tummidi
 

We are planning to deprecate the use of internal use store and any other features around password policy.  Internal User Store will be for dev only use.  

 Because of this, we are not working on enhancing these features. The recommendation is to use an enterprise identity provider which is much more full featured for Auth mechanisms and password policies

Thanks,
Sree


On Dec 6, 2018, at 5:37 PM, ryancutter@... wrote:

Hi, thanks I understand that.  But we'd like to prevent the last 3 (or 8 or 0) passwords being used.  Is this a feature others would be interested in?

ryancutter@...
 

Hi, thanks I understand that.  But we'd like to prevent the last 3 (or 8 or 0) passwords being used.  Is this a feature others would be interested in?
Sree Tummidi
 

Hi Ryan, 
This is intended behavior to prevent reuse of password essentially a password history check 

Thanks,
Sree


On Dec 6, 2018, at 5:04 PM, ryancutter@... wrote:

Currently during a change password operation, UAA has a hard coded check preventing the use of the most recent password.  Has there been any work on customizing this behavior to preventing the last X passwords from being used?  If not, is there interest in me building this feature and offering it as a pull request because we have a use case for this functionality?  I suppose this would be a password validation policy that people could apply.

But if it's already available and I'm just missing it, I'm all ears! :-)

Thanks, Ryan

ryancutter@...
 

Currently during a change password operation, UAA has a hard coded check preventing the use of the most recent password.  Has there been any work on customizing this behavior to preventing the last X passwords from being used?  If not, is there interest in me building this feature and offering it as a pull request because we have a use case for this functionality?  I suppose this would be a password validation policy that people could apply.

But if it's already available and I'm just missing it, I'm all ears! :-)

Thanks, Ryan

1 - 9 of 9