We are using a password store in our tests. This works fine on the machine that the task is created, however if I want to use this on a different machine it does not.
I have created a new Store and used a Store file (no extension). If I try to use this Store file on a different machine it complains that there are no passwords stored in it.
If I create a second store and reference the Store file on my first machine then it picks up the password(s). If I try to Export the Store and use that on my second machine then again it fails to recognise any passwords.
Are we able to use these password stored on different machines, i.e I want to check in the Store and use it on whichever machine I checkout to?
Hi there, there are two main modes of encryption for the password stores. One is based on the local OS encryption and one built on symmetric key encryption. In short, you should change the password provider to Key File.
The former is only portable if the OS supports it and that’s generally quite limited (by design as it’s intended for private credentials). Generally, for Windows this will not be the case unless it’s a roaming profile running on different physical machines (for what should be obvious reasons). For that reason if you’re storing local, personal credentials that’s a “safer” default but it’s not the one to use in a shared-credentials setting.
The latter is portable as it requires only possession of the key file and so sounds like what you need here. ORQA can create the key file, you just enter a path in the Preferences and it will instantiate the key file with the store.
As with other private key based processes, you must consider the mechanism to store and share these. We would generally recommend you could keep the store in the Model you wish to share amongst the team (though you aren’t obliged to) and then distribute the keys out-of-band (and never in the same model). For example, you may keep the key in pass or 1p or bitwarden, etc. The key is stored in ASCII format so it’s easy enough to share around even without secure file-sharing.
Then either different users can configure their workspaces to point to these or you can manage it another way, for example, in your ORQA.ini file you could set the default local password store configuration like:
-DlocalPasswordStoreKeyFile=${ORQA_SECRETS_DIR}/personal/.secure_key -DlocalPasswordStore=${ORQA_SECRETS_DIR}/personal/.secure_storage -DlocalPasswordStoreSecurity=keyfile
It’s also worth noting this has advanced a bit over the past year so if you’re on an older v1.4 build or earlier you may not yet have the multiple password-store feature but this is the preferred approach where you have tasks that may be running with distinct permission sets at run time.