Is there a standard way to do secure credential storage in vCO? In vCAC you can take advantage of "Endpoints" and "Credentials" which allow you to create some general configuration data and store credentials to go with it in a secure way. It doesn't appear that there is a way to unscramble the vCAC credentials with the vCAC plugin so I'm wondering if there is an analog for vCO to create the same kind of configuration. Another option would be is if there is an easy way to unscramble the password that comes from vCAC I could just use the vCAC entity model to solve my issue, but I don't see any documented way to do the unscramble that I could mimic using vCO.
We typically use a "securestring" attribute in a configuration element to store passwords. This attribute is stored in vCO's database in an encrypted format. It must be noted however that if you have the ability to write a scriptable task and do a call like: System.log("Password: "+mySecureStringVariable); then whatever is stored in the "mySecureStringVariable" will be displayed in plain text.
Another object is available for storing a username AND password - the Credential object. This one is a singular object that allows you to specify a username and password. You can do a system.log of the username but when you attempt to log the password, it is obscured by ****** (as tested with vCO 5.5 GA - earlier versions may have allowed for the display of plain text copy of the password). There is also a method that allows you to checkpassword by providing a string input and it will return true/false if you provided correct password. I'm unsure how this behaves when used for calling other things that require a password.
In either case above, if you wish to store the info within vCO for use by one or more workflows/actions, then you should store the values in a Configuration Element.
We typically use a "securestring" attribute in a configuration element to store passwords. This attribute is stored in vCO's database in an encrypted format. It must be noted however that if you have the ability to write a scriptable task and do a call like: System.log("Password: "+mySecureStringVariable); then whatever is stored in the "mySecureStringVariable" will be displayed in plain text.
Another object is available for storing a username AND password - the Credential object. This one is a singular object that allows you to specify a username and password. You can do a system.log of the username but when you attempt to log the password, it is obscured by ****** (as tested with vCO 5.5 GA - earlier versions may have allowed for the display of plain text copy of the password). There is also a method that allows you to checkpassword by providing a string input and it will return true/false if you provided correct password. I'm unsure how this behaves when used for calling other things that require a password.
In either case above, if you wish to store the info within vCO for use by one or more workflows/actions, then you should store the values in a Configuration Element.
Hi, Credential object has been deprecated. And configuration element can be displayed in plain text.
May I ask what is the current secure credential storage method?
@mayank_goyal Thanks for your reply. However the use case is to store credential in a place like configuration element (set and forget) and workflow will retrieve it to access accounts/vms. On top of that there is no way of displaying the credential in plain text.
With EncryptionService, there is still a need to store the encryptedString and key somewhere in order to retrieve the "credential". And that somewhere could be configuration element which did not solve the initial problem, just more steps. I hope I understood the service correctly.
i guess there are two original requirements
- Secure the passwords during printing/viewing
- Avail passwords on-demand
Using EncryptionService, we can have the encryptionkey in one place and the passwords in different places. With this, you can keep the encrypted passwords in the configuration element and no one will access them unless the key is there.
Now, keep the key in a separate place and create an action that will decrypt the passwords on demand seems like a good idea.
PS: just saying we can even encrypt the key and spread it in parts and do a double decryption whenever needed. #cringe