Allow CF Authentication based on Tokens - user and client tokens

[strehle]

Please provide details on the following items. Failure to do so may result in deletion of your feature request.

Request in short:
Enhance the cf auth command with a parameter --token or --assertion (the name can be defined later). The content of this token should be either a user token in order to perform a jwt-bearer or a client token in order to perform a client_credentials grant with federated trust.

What's the user value of this feature request?
Security improvement because we can omit secrets and and we can finally omit passwords.

Who is the functionality for?
CF Authentication. "cf auth" command

Example
With
cf auth --assertion <jwt-token> we can replace cf auth USERNAME PASSWORD --origin

Use jwt bearer instead of password grant flow. JWT bearer does not need to have an origin because the origin is in the token

and With
cf auth --assertion <jwt-token> --client-credentials we can replace cf auth CLIENT_ID CLIENT_SECRET --client-credentials

Use federated client credential flow. Trust between external system and CF must be setup before.

Who will use this feature?

Enterprise users.
All other users who dont want setup their password in a command line tool, but currently must use --sso

How often will this functionality be used by the user?
Each authentication of users and clients. With this we can link github to CF and we can map a github action authentication to a CF client so that you can do cf push within a github action. (you can do this currently but now you need to store CF secret in github)

Who else is affected by the change?
No breaking change but an enhancement only

Is your feature request related to a problem? Please describe.
The problem, that you need to do --sso for users and you dont have a solution for workload identity authentication, means linking a JWT provider to CF. K8s could be linked to CF.

Describe the solution you'd like
See examples with cf auth , Allow cf login based on a token from another Identity Provider without using a password or secret.

Describe alternatives you've considered

Additional context
cloudfoundry/uaa#2838
https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token

[damzog]

And as discussed in slack: It would be really usefull to keep the option to have CLIENT_ID in the command to be able to use custom clients (otherwise cf client would be used implicetly if I understand correctly):

cf auth CLIENT_ID --assertion <jwt-token> --client-credentials

[strehle]

And as discussed in slack: It would be really usefull to keep the option to have CLIENT_ID in the command to be able to use custom clients (otherwise cf client would be used implicetly if I understand correctly):

cf auth CLIENT_ID --assertion <jwt-token> --client-credentials

Ok, so I am not against any extra options to configure client_id... my point was, I think we can work with one client which is namely the "cf" client, but if you see use cases to have extra clients , sure we can do
The Issue Ticket was more to make the requirement transparent. I am not an expert for cf cli so I cannot really create the PR soon.... but in worst case I try :-)

[strehle]

Ok, so I am not against any extra options to configure client_id... my point was, I think we can work with one client which is namely the "cf" client, but if you see use cases to have extra clients , sure we can do The Issue Ticket was more to make the requirement transparent. I am not an expert for cf cli so I cannot really create the PR soon.... but in worst case I try :-)

Please see #3397

During this enhancement I found out, that it is easy to be flexible with extra arguments, so you can do
cf auth CLIENT_ID --assertion --client-credentials

but also
cf auth CLIENT_ID CLIENT_SECRET --assertion
-> if you want use jwt bearer but you want pass another client with extra client authentication

If you do
cf auth CLIENT_ID --assertion
-> the jwt bearer is done with this CLIENT_ID but an empty secret as client_secret.

The default configuration in .cf/config.json uses cf client with empty secret, so if you omit a parameter the default is used