if cf misconfigured, still allow user to 'cf login --sso'

[drnic]

If a target CF has not been configured correctly, this PR still allows a user to cf login --sso. This is a "good thing". We should encourage authentication via browsers and password vaults.

Why Is This PR Valuable?

​
We should encourage all users to move away from providing passwords via CLIs in terminals. An oauth sequence into the browser allows the user to use their 1password integration.

Currently some users cannot use cf login --sso because their platform operator misconfigured their UAA prompts. This PR fixes this issue for those users.

What benefits will be realized by the code change? What users would want this change? What user need is this change addressing?

I am doing a video on cf login tips & tricks. I'll be promoting cf login --sso as my preferred method for ppl to login. Currently it's broken for some users.

Explain why this functionality should be in the cf CLI, as opposed to a plugin.

Its a fix to cf login.
​

Applicable Issues

Initial PR does not have i18n. I'll do this in a follow up PR.

How Urgent Is The Change?

I'd like to have this feature fixed for my video.​

Other Relevant Parties

UAA

[cfdreddbot]

✅ Hey drnic! The commit authors and yourself have already signed the CLA.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/165626330

The labels on this github issue will be updated when the story is started.

[abbyachau]

Hi @drnic could you please provide more information about this pull request:

Description of the Change

We must be able to understand the design of your change from this description.

Why Is This PR Valuable?

​

What benefits will be realized by the code change? What users would want this change? What user need is this change addressing? -->

Explain why this functionality should be in the cf CLI, as opposed to a plugin. -->

​

Applicable Issues

How Urgent Is The Change?

​

Other Relevant Parties

​

[drnic]

Ah, sorry for deleting all the text. The start of it said "you must have signed the CLA" and I assumed I could ignore it.

[drnic]

@abbyachau FYI - your prompts for me above are (very?) different from https://github.com/cloudfoundry/cli/blob/master/.github/PULL_REQUEST_TEMPLATE.md

[drnic]

@abbyachau I've updated the description with your questions and my answers. Thanks + sorry.

[abbyachau]

Ah thanks @drnic I've updated the pull request template unsure why so much of it was obfuscated.

[abbyachau]

Thanks for updating @drnic; we are currently rewriting the cf login command; for reference here is our epic.

I'm struggling to understand how I would accept this story. Would you mind providing acceptance criteria so that I understand what the previous workflow looks like and what your proposed changes are. Something similar to:
Previous workflow
Given a user with a misconfigured CF
When I run cf l --sso
I expect the command to error with the following...

Current workflow
...

[drnic]

Acceptance steps:

1. Run cf dev start (as a simple way to bring up an example CF environment that does not support cf login --sso).
2. Run cf login -a https://api.dev.cfdev.sh --sso and the user should be prompted with the URL for the passcode; and then be allowed to complete the login sequence.

Err, sorry I didn't write them like cucumber steps.

[abbyachau]

Thank you. No problem, it was just an example - appreciate the acceptance steps.

[abbyachau]

Hi @drnic thank you for this pull request. We were planning to review/move forward with efforts detailed in #1617 and as such will not be pulling in this feature. As you know, we hope to finish rewriting cf login and after we complete that work, we look forward to working with the OP for #1617. Please let us know if you have any questions or feedback, thanks. I've also updated our pull request template - thank you for letting us know about the confusion.

[drnic]

I would appreciate this PR being pulled into current cf cli please. I don’t feel like the explanation above included an explanation why this isn’t a valuable bug fix for current users. :(

[abbyachau]

After some digging, this request is not to enhance cf l --sso but to allow users to always see the prompt for Temporary Authentication Code . @drnic please correct me if I'm wrong.

I'm tagging UAA PMs (@cwang-pivotal, @dbeneke, @aramprice) and I'll try to summarize what's going on here to get your feedback.

Currently, even if users do not have an identity provider set up, they can use cf l --sso which will return the following:

± |master U:1 ?:6 ✗| → ./cf l --sso
API endpoint: https://api.arsicault.cli.fun

Temporary Authentication Code ( Get one at https://login.arsicault.cli.fun/passcode ):

And when they go to that url and enter their credentials, they can retrieve the passcode to log into their cf instance.

It appears that this is unintended behavior, according to the UAA: Passcode prompt is sent back by UAA as part of the info call only if a SAML/OIDC provider is set up.

However this is a workflow the CF CLI supports, and we cannot remove support for in the V6 CLI. Furthermore, we believe this is a workflow that some users might use for password managers like LastPass - although we have not validated this assumption.

The question here is whether this is a workflow that the UAA team supports as this pull request makes that workflow more explicit, and more of a 'real' feature.

[drnic]

I believe this issue has appeared on someone’s SO issue https://stackoverflow.com/questions/60210238/cloudfoundry-cli-login-not-working-credentials-were-rejected-please-try-again/60217563#60217563

Could we revisit this?