Solved

Encrypting

  • 27 September 2021
  • 3 replies
  • 94 views

In IAM it is possible to specify environment specific settings (similar to app.config in C#). See Authorization >> Applications >> Properties. Is it possible to encrypt fields here (e.g. in case of a security token or password?)

icon

Best answer by Mark Jongeling 27 October 2021, 08:58

View original

3 replies

Userlevel 7
Badge +23

Hi Rene,

The properties you are referring to are the Extended properties. These properties can be used to alter the behavior of the GUI. For a complete list, see the docs: Extended properties · Thinkwise Docs (thinkwisesoftware.com). These fields cannot be encrypted.

What kind of information would you have liked to put/name there and to what purpose? Maybe there's something else we can recommend.

Sorry Mark, the word 'Encypting' was incorrect. I meant the following…

I use security tokens and passwords in the extendend properties. These parameters are for calling external APIs. These settings are environment dependent. However, I want eg a password or token not to be readable from the screen. An option to indicate that it is a 'password' field type would be a nice option

Userlevel 7
Badge +23

Hi Rene,

Using Extended properties is possible, creating session variables for security tokens and passwords. That way you can use them inside SSMS code and process/system flows. Only Root administrators in IAM may see and create Extended properties for applications in IAM making is quite secure. We don't recommend making every developer/user a Root administrator in IAM; only people that truly need this role should have it. Marking data as "Password” is something we could do but it does not make it impossible for other Root administrators to hide these secrets.

Alternatively you could make a table with those secret credentials in your end product and only give rights to the correct users. That would mean it doesn't have to be offered as session variables but can be easily obtained with SQL queries with your Process procedures or others.

Most secure option would be to have an Azure Key Vault or AWS Secrets manager. These can hold your secrets away from you IAM and End product and can only be obtained using a HTTP Connector process action. This will have the benefit of your users never seeing the secrets themselves. More info on it here: 

Azure: https://docs.microsoft.com/en-us/rest/api/keyvault/vaults/get
AWS: https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html

Do these alternatives sound like a good fit for you?

Reply