In current version of TSF it is seems not to be possible to synchronize from TSF to IAM when the target DB credentials differ from the TSF Webservice credentials.
Because of this, in case the credentials cannot be made equal creating a deployment package seems to be the only way to sync IAM, which is not desirable, because this is to much complicated. Especially in case of a making small changes, like a little adjustment in a roles, this cost to much time.
I would expect a possibility to enter credentials before starting the sync process or save the credentials (securely) in the IAM Configuration.
Or, have I missed something and is there already an easier way?
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.
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.
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
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
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
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:
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:
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.