Best Practice for Securing API Credentials in Web Services Connector After Rule

[sxxnex (sojeong park)]

I am currently using the Web Services Connector in SailPoint Identity Security Cloud and implementing an After Rule.

Inside the After Rule, I am calling an external API and modifying the response based on the API result.
At the moment, the API credentials (client ID and client secret) are hardcoded directly in the rule, which is not ideal from a security perspective.

I would like to ask:

• Is there a recommended way to secure or encrypt API credentials when using them in an After Rule?

• Is it possible to store credentials securely (for example, using Application attributes, Secrets, or another secure storage mechanism) and reference them in the rule at runtime?

• What is the best practice in ISC to avoid hardcoding sensitive values like client secrets in rules?

Any guidance or examples would be greatly appreciated.

Thank you!

[sidharth_tarlapally (TARLAPALLY SIDHARTH)]

Hi @sxxnex

Please refer to the SailPoint documentation below regarding handling sensitive data in source configurations:

Integrating SailPoint with Web Services

When configuring the source, do not hard code sensitive data. If sensitive data is hard coded, it can lead to that data being exposed when moving to a production environment. SailPoint recommends putting sensitive information in the encrypted attribute value list in the application XML and then using the encrypted variable name when configuring the source.

Recommended Approach

1. Add the required attributes to the source configuration.

2. Add these attributes to the encrypted attribute list.
Note: This is a PATCH call, so please ensure all existing encrypted attributes are included as-is, and then append the newly added attributes.
Using VS Code is recommended for easier editing and validation.

Usage in Rule

Once configured, you can access the attribute in the rule as follows:

String clientId = application.getAttributeValue("AppClientId");

This will allow you to securely retrieve the value within the rule without exposing sensitive data.

Please let me know if you need any assistance with the configuration.

Thanks
Sid

[sxxnex (sojeong park)]

@sidharth_tarlapally

String clientId = application.getAttributeValue("AppClientId");

Hi Sid,

I’m getting a 401 Unauthorized error after switching to encrypted application attributes.

Just to confirm — for attributes added to the encrypted attribute list, is it expected that they can be retrieved directly using:

String clientId = application.getAttributeValue("AppClientId");

without any additional decoding or handling?

I want to make sure there isn’t an extra step required when accessing encrypted attributes in an After Rule, and that this method should return the plain value at runtime.

Thanks in advance for the clarification.

[vguleria (Vikas Guleria)]

Hi @sxxnex

Agree here with @sidharth_tarlapally , Please note that you need to use PATCH api call to add the sensitive field into encrypted block, if you use some other way of adding these field into this block, the encryption may not work.

In addition to that, you may also add suffic _CA in the field holding the encrypted value.

And when you are accessing this value via rule, it does not need to be decrypted or so because it is encrypted using VA passpharase only and the system can decrypt it automatically.

Thank You.
Regards
Vikas.

[sxxnex (sojeong park)]

@sidharth_tarlapally

application.getAttributeValue

I configured the source with the following attributes:

[
  {
    "op": "add",
    "path": "/connectorAttributes/custom_client_id",
    "value": "example_id"
  },
  {
    "op": "add",
    "path": "/connectorAttributes/custom_client_secret",
    "value": "example_secret"
  }
]

When calling them in the rule as shown below, the API call works as expected:

String clientId = (String) application.getAttributeValue("custom_client_id");
String clientSecret = (String) application.getAttributeValue("custom_client_secret");

However, after adding custom_client_secret to the encrypted attribute list, the API call starts returning a 400 error.
The rule itself remains unchanged between the working and failing cases.

Is there anything else required when using encrypted attributes?

[sxxnex (sojeong park)]

What do you think about using secretAttributes instead?

[sidharth_tarlapally (TARLAPALLY SIDHARTH)]

@sxxnex
You mean you are getting 400 while making PATCH API call to update “encrypted” attribute?
Please share a snapshot , mask any sensitive data.

Thank you

[vguleria (Vikas Guleria)]

Hi @SoumyaVaramballi

400 error message is weird one, i personally do not think it is coming due to adding the secret to encrypted block. Can you please check if after running the PATCH api, you see these custom_client_id and custom_client_secret in encrypted form on source.

Do note that if you already had these variabled defined on the source, then you should either delete them and re-add them or replace them instead of running PATCH with add.

I hope this helps.

Regards

Vikas.

[sxxnex (sojeong park)]

The source already uses the test_client_id and test_client_secret attributes.
When both attributes are not encrypted, declaring and using them in the rule as shown below works without any errors:

String clientId = (String) application.getAttributeValue("test_client_id");
String clientSecret = (String) application.getAttributeValue("test_client_secret");

However, when test_client_secret is added as an encrypted attribute, the following error occurs:

Error: The application script threw an exception: java.io.IOException: Server returned HTTP response code: 400

Based on the URL where the error occurs, it appears to fail during token authentication when calling the API inside the rule.

[patrickboston]

Your custom attribute names are supposed to end with _CA per the documentation for the web services connector. Trying changing the name and see if it makes a difference.

[sxxnex (sojeong park)]

@vguleria

400 error message is weird one, i personally do not think it is coming due to adding the secret to encrypted block. Can you please check if after running the PATCH api, you see these custom_client_id and custom_client_secret in encrypted form on source.

Do note that if you already had these variabled defined on the source, then you should either delete them and re-add them or replace them instead of running PATCH with add.

I hope this helps.

Regards

Vikas.

After adding custom_client_id and custom_client_secret to the encrypted attributes, the values appear in encrypted form when retrieved from the source.

[sxxnex (sojeong park)]

I created new attributes with _CA appended to the name and tested them, but the result was the same.

[patrickboston]

You must be doing something wrong. Once the attribute name is in the encrypted list and it’s PATCHed to the source (ending with _CA), it should work. Here is the documentation Custom Authentication

[patrickboston]

Here is someone else doing it successfully

Add Encrypted attributes in the Source so that I can use those in the before and after operation rule

Hi Team I have a requirement to make an additional API call to different system in my before rule and wanted to save those credentials on the source in custom attributes as encrypted. I am not able to find any relevant article. I tried patching the source with Attributename_CA but its not encrypting those. Any Suggestions

[vguleria (Vikas Guleria)]

Hi @sxxnex

Can you please share the exact details of the error message where do you see it. And also please send the screenshot of these attributes as they have encrypted values, i think it should be fine to share them.
Please make sure to mask any sensitive information.

Thank You.

Regards

Vikas.