[FEATURE] SSO Login Option

[axherrm]

What area do you want to see improved?

terraform provider

Is your feature request related to a problem? Please describe.

Using the provider with least amount of configuration needs

Describe the solution you would like

If no other authentication methods are provided (User/password, clientID/secret, CF_HOME, etc), instead of failing the CF CLI could be called interactively with --sso. The BTP provider also provides this option:
https://registry.terraform.io/providers/SAP/btp/latest/docs#single-sign-on

Describe alternatives you have considered

No response

Additional context

No response

[github-actions]

Thanks for the feature request. We evaluate it and update the issue accordingly.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[lechnerc77]

Some remarks and a question: The Terraform provider for SAP provides the option as a "last resort" for local execution mainly for exploration and trying things out. In any case we do not encourage the usage of --sso.

Having said that, the situation with the Cloud Foundry provider is different, as you can use the CF CLI for the sign-on and then use it in the provider as described here: https://github.com/cloudfoundry/terraform-provider-cloudfoundry/blob/main/Authentication.md#using-cf-cli-configuration

Question: Do I understand your request correctly that the provider should fall back to cf login --sso on behalf of the caller if no authentication is provided at all?

[axherrm]

I understand that this is probably not useful for everyone and if I think about it again, I would agree that it's maybe not the best idea to use it as general fallback.

But in my opinion, providing the option by introducing a parameter for it or reading some ENV var to activate it, would do no harm to users that don't wanna use it and would be a nice option for people like me.

To elaborate a bit on my use case:

My team is using terraform (and this provider) to set up our product in new BTP (and thus CF) landscapes. We don't use terraform to manage existing infrastructure. I know that this is not what terraform is mainly targeted for, but for us the declarative approach is very useful for setting up regions, so use it just for this.

Because there a in most cases some things to adjust and fix on our side when setting up new regions, we don't do this setup with terraform in pipelines but rather on our devices. Thus, SSO comes very handy because we get rid of providing technical credentials. Only in our team, we have 3 products which could probably benefit from such functionality but I'm sure there are teams which are also interested.

Regarding differentiation between the reuse of the .cf/config.json and a explicit SSO activation: When me (and also other colleagues who are not that experienced with our setup scripts) use it, not having to do anything before running tf apply is more convenient and also shifts the definition of the correct API endpoint to the terraform instead of letting the user login by himself first.