Share all details about your problem, including any error messages you may have received.
I have a WebServices Connector application, where secrets are stored as plaintext in the application definition as an entry in the Attribute Map. The keys for these secrets have been added to the “encrypted“ entry (example below), however after saving the application definition, IIQ does not encrypt the secrets.
@tim089 Please share your app xml. I tried this in my sample web service app and is working fine. Please also check if you are getting any error in logs after saving.
In SailPoint IIQ, adding a key to the encrypted attribute does not trigger the system to encrypt a plain text value for you. Instead, that setting tells IIQ: “The value already stored here is encrypted; please decrypt it before using it in a rule or workflow.”
To fix this, you must first encrypt the value manually (using the IIQ console or a tool like iiq encrypt) and then paste that encrypted string into the XML.
@igaqaiseriqbal It does encrypt the plain text automatically if the attribute is added to encrypted attribute. I have tested this for many app connectors (jdbc, webservice, etc),.
Thanks for the input, Neel. I’ve found that while standard password fields in the UI might auto-encrypt, custom attributes added to the encrypted map in a Web Services Connector don’t always behave the same way.
To be 100% safe and ensure the connector decrypts it properly at runtime, I’m manually encrypting the value via the IIQ Console first. This ensures the string in the XML starts with the required 1:encrypted: prefix.
In SailPoint IdentityIQ, adding an attribute to the encrypted list does not always encrypt the value automatically for Web Service connectors. To ensure the secret is stored securely, we encrypt the value using the IIQ console (iiq encrypt) and store the encrypted string in the application XML.
Thanks all. I have resolved this by placing the encrypted string in the xml instead of the plaintext.
Alternatively, I found that adding the key name to the “encrypted” attribute, saving the xml, then saving the application definition through the UI automatically encrypts the fields indicated in the “encrypted” attribute.
I’m now facing another issue where I suspect the x-api-key is not being decrypted properly. I have added “x-api-key” to the “encrypted” attribute value list and observed that it has been encrypted in the xml. However, Test Connection fails after this. I compared to another copy of the xml where the only difference is the x-api-key is unencrypted and not in the “encrypted” attribute value list.
Is this related? This is an Oauth WebServices app. I saw in the documentation that for WebServices connector apps using custom/no auth, x-api-key has to be renamed to x-api-key_CA but I do not think this is applicable in my case. Does anyone have any advice? Thank you.
Great to hear you got the encryption working in the XML.
The failure you’re seeing is almost certainly because the connector is sending the literal encrypted string (starting with 1:encrypted:) in the HTTP header. While adding it to the ‘encrypted’ list handles secure storage, it doesn’t automatically trigger decryption during the actual API call for custom headers.
Even for OAuth applications, using the _CA suffix is the most reliable way to signal to the Web Services execution engine that a value must be decrypted before it is injected into a header.
Try this specific configuration:
Rename the attribute in your XML to x-api-key_CA.
Ensure x-api-key_CA is included in your encrypted attribute value list.
Update your Header value in the UI to reference it as: $application.x-api-key_CA$.
This forces the decryption layer to trigger regardless of the Auth type you have selected.If it still fails, check the IIQ Console or Logs. If you see the 1:encrypted: prefix in the outgoing outbound call, it confirms the decryption step is being skipped.