@Harm Horstman This is missing since TWP 2022.1 in which they revised the synchronization and deployment, pretty annoying indeed! @Anne Buit mentioned last week that this will most likely be supported again in TWP 2023.1, let's hope it will make it to the release.

Thanks @Arie V, I really hope this will be solved soon, we are using the synchronization mechanism a lot, especially during test and the commissioning stage.

@Anne Buit, is implementation of this already scheduled? Or do I need add a ticket in TCP for this?

Hi Harm,

Allowing alternative credentials for pooled application access, synchronisation, code execution and unit testing is indeed planned for 2023.1.

Note that it will require you to set up encyption key storage for the Indicium(s) hosting the development environment.

Feel free to submit a ticket if you want to keep posted on the progress.

Is the Managed Identity also part of this feature? I really would like to setup this feature with managed identity so there is no need to store credentials anywhere.

Support for managed identities is separate feature that we have our sights on for an upcoming release. Not just for database connections but also for Azure storage and other cloud services.

@Mark Jongeling how is this implemented? I still cannot find nowhere in IAM to connect a own set of credentials per server.  

@rustie 

More information about it here: https://docs.thinkwisesoftware.com/blog/2023_1#deployment---pool-user-credentials

same as Freddy. cannot find that option. i want to use it to easily create changes from my on prem SF to my end application on Azure

@rustie , You can now (2023.1) open the Software Factory using the Universal GUI. After opening the menu item IAM configurations, you can set pool user credentials per configuration.

@Mark Jongeling Why are these menu items not available through the Windows GUI of the SF?

I really don’t get why you would have inconsistent menus between the different GUI’s, nor do I get why we would open the SF in the Universal GUI if it is only partially supported…

Another question on this topic, the Docs you refer to state the following: “If added, these credentials are safely encrypted”. I assume this encryption only works if Encryption in Indicium is enabled?

If so, a couple of follow up questions:

• Could you please have the documentation updated accordingly?
• Could it be indicated which other columns are encrypted by Indicium (if any)?
• In the Release Plan for 2021.3 three different encryption options were mentioned, could a blog be published explaining why this solution was chosen and how it works?

Hi Arie,

The 2-tier Windows GUI is not able to safely encrypt credentials as it does not have access to the key vault. If the 2-tier Windows GUI would have access, encryption in itself would lose its value.

Having the Windows GUI store the raw credentials to the database to have Indicium encrypt them asynchrounously is not safe either - we do not want the raw credentials to be in the database at rest at any point, nor do we want the unencrypted credentials to be present in process variables in process logic - it would be trivial for a developer with access to the Software Factory database to intercept them.

The only solution currently is to use Universal for the SF for this specific feature. If this is a problem, we could also share the HTTP calls needed to manually execute this process flow.

The encryption indeed uses encryption in Indicium. When attempting to use this feature without having encryption in Indicium enabled, you will get the following message:

This environment has not been configured to allow data encryption. 
Detailed information about configuring data encryption prerequisites can be found in the online documentation.

Currently, only the pool credentials for runtime configurations, iam synchronisation and applications in IAM will be encrypted. We plan on allowing encryption for other configurations as well such as file storage accounts. However, applying encryption would render them usable by Universal and Indicium only.

Work is being done on making the Windows GUI compatible with Indicium. As soon as this is finished, these differences between UI’s due to architecture will be a thing of the past.

Regarding the various types of encryption, the chosen solution in 2022.2 is well-suited for encrypting credentials. Even when trying to load the values via the API, it will remain encrypted. Decryption is an explicit activity that can be done on-demand, for instance when calling an API that requires the credentials.

A different type of encryption would allow for the data to be always decrypted when selecting via the API but stored in the database in an encrypted way. This ensures the data is encrypted at rest, even for database  administrators. But it also causes trouble with logic using the data, sorting and filtering and such. Built-in SQL Server features such as transparent data encryption allow for encryption at rest without the beforementioned drawbacks, except the data would be accessible to database administrators.

I’ll forward the request to share some more information about encryption and decryption with the appropriate people.

Closing the topic to prevent further discussions.

Please create either a Conversation or Question if any more information is desired.