Can't log in to bluemix using "cf login --sso"

I'm trying to automate deployment as part of an external build process. I'd like to be able to run a few cf commands. I would like to login at the command line and would prefer not to have my password exposed in a script. Looking at cf help login I see there is a recommendation to run cf login --sso. The documentation for the cf commands doesn't have any mention of the --sso option. When I run it I'm just brought to an empty prompt '' e.g.:

7 answers

Currently, cf login -sso is not exploited in Bluemix. But I don't see how this would help you. -sso is meant to allow you logging in with a one-time password, that you retrieved previously via a URL. This would mean that for each script execution, you would need to log in with the browser and retrieve a one-time password, that you need to feed into your script.

I understand your bad feelings about embedding a password into a script. The only solution to avoid that is to leave out the password parameter and enter that interactively each time you run the script.

@RobertCollins - Not sure if this fits your use case, but another option is to leverage the IBM DevOps Service to help with your auto-deployment. You are able to define stages within a pipeline that is targeted towards an organization and space for which you are a member. No password embed required. The stages can be triggered to build and deploy by SCM commits or completion of prior stages. More info on the Build & Deploy capabilities within IBM DevOps Service.

Robert, I don't know of any concrete plans, but I am still struggling with your use-case. From your initial question, it looks like if you want to have a model similar to ssh public/private keys? That is not what -sso was meant to solve. It will create you a passcode that will work once. You can execute your script once with that passcode, after that, this passcode is invalid.

This -sso login variation is meant to support login flows over e.g. SAML, where no server is available to verify a user ID / password combination. So you still have to log in interactively and obtain a SAML token to get that one-time passcode.

There is no easy answer. Fact is, that the only way to login to the cf command line tool is to provide a user name and a password. You cannot provide a hash value, a private key or similar. This is not supported by the server. So somehow the cf login command must be provided with the password. You can find several ways to obfuscate the password in your script, e.g. (not tested)

But this is only an obfuscation, to avoid people looking over your shoulder to read the password. You can develop more sophisticated obfuscation mechanism, but at the end, cf login is called with the clear text password.

IMHO, most important is to not provide a password on the command line interactively to avoid the password being in the shell history. Providing that password within the script - obfuscated or not - is a decision that you need to make yourself. If you want real security, you need to interactively enter the password. I don't see any other option.

I was reading more about the login process. I think I misunderstood what cf login was doing. I didn't know that cf login gave me access and refresh tokens which would continue to be used. I had assumed a short lived session (I didn't think about how this worked). I've just always logged in each time I wanted to use the service. Given the login is persistent, I don't need to include a login step in my script provided I've logged in to Bluemix on the builder before. I can use a CF_HOME env variable to separate out different logins as well.

The solution that teams like IBM ActiveDeploy service used was using Jenkins to house the Bluemix password secrets and run the command-line "cf push" deployment scripts to push new versions of the app. Jenkins has a secret storage manager and permissions on jobs so you can configure a read-only deployment job, which pulls in the password from the Jenkins secret manager as an environment variable into the push-script, and the push script can be configured/written to not expose that password to the console of the job.

Note their solution also took in other environment variables as parameters to the deployment job like the BM region, so the same script/job could be run once to deploy in ng.bluemix.net (Dallas) and a second time to deploy in eu-gb.bluemix.net (London).