Secure storage of password value for use with PowerShell connector
I have a requirement to send a password in clear text within the HTTP header (only protection is SSL) when calling the SAP ODATA API. This cannot be in encoded form, so I cannot use the standard approach used say when calling the Exchange API to provision a mailbox. Is there a way that an encoded password can be accessed and decoded from within the Identity Broker configuration itself (e.g. via a $variable), so that it is not exposed to anyone viewing the IdB configuration?
As an alternative to the Exchange style file-based encoding mechanism I am saving the Base64 encoded password to a text file for now, but this is not exactly secure. If the answer to the above is no, and there are any alternatives that you are aware of please advise.
Customer support service by UserEcho
Nothing provided OOTB yet. I've updated
IDB-759to include this use case.
Why can't the Exchange password thing be used? The libraries that are used should have a few overrides, I believe it can either output the password in plaintext, or there are ways to to turn it into plaintext.
Adam van Vliet - happy to be proven incorrect, but I've not been able to decode the encoded password using the OOTB PS library, and had to revert to using Base64 encoding. I've adopted a similar approach but used my own code to read from the file for sending in the header, i.e.
This encrypts it: http://powershell.org/wp/2013/11/24/saving-passwords-and-preventing-other-processes-from-decrypting-them/
This decrypts it: http://blogs.msdn.com/b/timid/archive/2009/09/09/powershell-one-liner-decrypt-securestring.aspx
Just make sure you encrypt it using the service account.
Thanks Adam van Vliet - everything I've tried so far hasn't successfully decrypted it but I will give this a go now.
Thanks Adam van Vliet - can work with this now. The trick both the blogs and I were missing before was the | ConvertTo-SecureString bit when loading from the file (as the service account!):
Happy with the current implementation - looking forward to a new feature one day which makes this redundant