-
Notifications
You must be signed in to change notification settings - Fork 973
Description
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