Handling Env. Tokenizers in IIQ CI/CD? How to Manage Tokenizers When Using One Build for All Env.?

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Hi Community,

We are implementing a CI/CD pipeline using Harness for SailPoint IdentityIQ on AWS and ran into an issue related to environment‑specific tokenizers during the build and deploy process.

Current Setup

We maintain multiple environment-specific properties files (e.g., dev.target.properties, qa.target.properties, prod.target.properties).
During the Build stage in our pipeline (Harness), tokenizers get replaced inside these files.
We generate one single build artifact, and this artifact is deployed to multiple environments (DEV → QA → PROD).

The Problem
Because the token replacement happens during the build:

If the build picks up DEV tokenizers,
then the same artifact is later deployed to QA or PROD,
the properties now contain wrong values for that environment.

We want to avoid baking environment-specific values into the artifact at build time to prevent promotion issues.
Our Requirement
We want a clean approach where:
DEV properties get DEV tokenizers,
QA properties get QA tokenizers,
PROD properties get PROD tokenizers,
…but WITHOUT regenerating a new build per environment.

Essentially:

How should environment‑specific tokenizers be handled in a SailPoint IIQ CI/CD pipeline when using a single build promoted across multiple environments?

Questions for the Community

What is the SailPoint‑recommended approach for handling environment-specific values in IIQ CI/CD?
Should token replacement happen only during Deploy, not during Build?
How do teams structure:

properties files
tokenization logic
SSB configuration
environment overrides
to ensure the same artifact can be safely deployed across DEV/QA/PROD?

If using SSB, what is the recommended way to handle:

dev.target.properties,
qa.target.properties,
prod.target.properties
so that they inject correct values at deploy time?

Any architectural recommendations, example folder structures, or CI/CD patterns that align with SailPoint best practices would be extremely helpful.
Thanks in advance!

2

If I understand it correctly, the token issue happens because you are moving artifacts from one environment to another. Best practice is to generate a .war file for each environment.
We use SSB and define list of servers and their corresponding environment in server.properties file like shown in the screenshot:

image
image1540×200 17 KB

Based on which server the build command is run, SSB will take the properties file of that environment.

3

Hi @srikanthetikala

Building a separate war file for each environment is how it is done.

1 Like
4

Hey Srikant, you can build a separate war file for each environment but I feel that might be too much work. other way around is using hashicorp and set token lifecycle management within your CI/CD pipeline that way each environment is set with automation and respective key.

https://developer.hashicorp.com/vault/tutorials/get-started/introduction-tokens

Please if my response has helped you, help me marking it with a solution

5

Hi @srikanthetikala

I agree with @paul_hilchey, using separate wars per env is how I’ve traditionally seen it done.

However, if you do have a strict requirement to only generate 1 build artifact you could remove the tokenization from the build and instead do the tokenization once the war is deployed and before you run sp.init-custom.xml to import your custom artifacts. You would have to tokenize the IIQ_HOME/WEB-INF/config/custom directory as that is where sp.init-custom.xml will pull from to import.

1 Like
6

If you have good source control and a good CI/CD pipeline, then building and deploying the same git tag (or equivalent) is a reliable way to ensure you are deploying the same thing in your different environments.

7

@srikanthetikala Building a separate war files for each environment is how most of the organization prefered as this gives us flexibility to control the macro injection via SSB itself. However, if you want to do it via single build file, then you need to build a supporting service to replace the tokens/macros, like shell script to replace the macros as per your environment specifications after the build.

Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(:heart:, :+1:, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.