-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Password Deprecate Request #1085
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @strehle,
❓ Can you please add a proposed timeline for the deprecation similar to this one for capi v2?
It would be great if there was an intermediate step (similar to the capi v2 deprecation) where passwords are turned off by default, but can be turned on again.
hi @ameowlia
Thank you for your feedback, I added a proposed timeline in https://github.com/strehle/community/blob/rfc-deprecate-passwords/toc/rfc/rfc-draft-deprecate-passwords.md#timeline
Described the changes in phases. |
@a-b could you please provide feedback if you have any on this RFC because it also proposes CF CLI changes. |
Thank you for bringing this to our attention. We support improvements in security as long as CF CLI remains backward compatible with older deployments. |
@a-b do you have any comments on the proposed phased approach in https://github.com/strehle/community/blob/1494e6b766f3b7dcacf76bd8eacd14e75097307d/toc/rfc/rfc-draft-deprecate-passwords.md?plain=1#L64-L79? |
I am curious about the expiration and rotation of tokens. Should we implement a policy that requires regular rotation by default? |
We discussed this RFC during the TOC meeting on 4th of March and decided to start the FCP with the goal to accept the RFC. The comment is not blocking the RFC as discussed during the meeting. |
Short: Deprecate Password Grant in UAA.
Consequence is: Build an alternative in cf login / cf auth because until now the password grant is used always in case of CF user authentications. UAA supports JWT bearer, but this should be improved in order to consume it and to not block customers, because of missing functionality.
Most of technical details in cloudfoundry/uaa#3285
@cloudfoundry/toc
For easier viewing