Enhancing Logging Efficiency in IDN: Part Two

I’m delighted to follow up on my previous article on Optimising Log Retrieval in IDN , which garnered positive feedback. In this installment, we’re taking our approach to the next level.

In the context of our internal cloud system, log lines may not arrive in proper order. Consequently, when these log lines are retrieved and presented, users often face the challenge of manually rearranging them. Moreover, if a logging line is executed multiple times (such as in a loop), managing multiple entries can be cumbersome, making it difficult to discern the chronological sequence.

Let’s revisit one of the examples from the prior article to illustrate how log lines are currently written:

By adopting a slight modification to this method, we can write multiple log lines with a standardized prefix to easily identify the associated identity.

Taking it a step further, we introduce a logNumber and encapsulate the entire logging structure into a method that is repeatedly executed:

Key differences from the previous code include the introduction of logNumber as a newly initiated counter and the implementation of the logMessage method, which is executed on every line, printing the logNumber and incrementing it accordingly.

The result of this modified code is a more streamlined output, exemplified as follows:

While I won’t provide a full code execution example here, it’s evident how this approach simplifies handling logs in loops or complex rules with multiple log lines, making it easier to decipher the order of execution.

To summarize the main advantages:

  1. Single method to streamline the logging mechanism.
  2. logNumber facilitates pattern-following, making it easy to discern the execution order.
  3. A single instance of log.error, easily adaptable to log.info or other log levels without the need to edit each log line individually.

I collaborated on this work with my colleague Kenny Li, a Senior Solution Architect at SailPoint, with whom we together transformed my individual works into an easily applicable method.

As this will likely be my last blog for the year, I wish you all a Merry Christmas and a Happy New Year!!!

Optimizing Log Retrieval in IDN Cloud Rules

When it comes to extracting logs from cloud rules, our usual route involves reaching out to support or ES. However, if these logs lack proper formatting, sifting through them for a specific user run can be quite challenging.

Here’s a method I employ to streamline the tracking of logs for individual runs, making it easier for you to obtain them via the support team.

Log Prefixing for Enhanced Clarity

To facilitate the process, each rule type has access to some identity data, which we utilize as a logPrefix in every log line within the rule.

While there may be alternative approaches for various rule types, I’ve outlined my preferred methods below.

IdentityAttribute / AttributeGenerator / AttributeGeneratorFromTemplate / Generic Rule

For rules with access to the identity object, you can create a logPrefix attribute to append to each log line as follows:

Now, you can use this logPrefix to append to every log statement, like so:

BeforeProvisioning Rule

For rules with access to the plan object, use the following approach:

Now, you can incorporate the logPrefix in the log lines as mentioned earlier.

Correlation Rule

When dealing with the Correlation Rule and access to the account object, fetch a primary identifier (e.g., STAFF_NUMBER) for enhanced identification:

ManagerCorrelation Rule

For the ManagerCorrelation Rule and access to the link object, retrieve a primary key (e.g., Userid) for better association:

BuildMap Rule

Finally, for the BuildMap Rule and access to cols and record of the accounts, fetch an attribute (e.g., EMP_NO) via a map for logging:

Streamlined Output Request

When requesting logs, provide the formatted logPrefix, the organization name, and the timeframe. For example:

 Generate sAMAccountName - [EMP001]

The logs, once fetched, will be neatly formatted and easily identifiable, even in scenarios where the rule runs for thousands of users but you need information about just one user for troubleshooting:

I hope this aids you on your rule journey! If you have any questions, feel free to reach out.

IdentityNow Rule Validator 3.0 + Generic Rules

As you may know, for IdentityNow Cloud Rules – they have to be submitted to SailPoint for upload to the tenant. We have a rule validator tool to validate IdentityNow rules for malformed or incorrect code fragments, and help make sure they conform to the SailPoint IdentityNow Rule Guide before rule submission.

We have had a great release of a brand new IdentityNow Rule Validator v3.0 (currently sitting on 3.0.23 at the time of writing). This is a major jump forward with mention in release notes (many more enhancements than what it states 🙂 ) 

  • BeanShell linter will now validate syntax and usage to help discover issues in your code before you deploy
  • A watch option which continually monitors and validate/lint  your code while you develop.

Download: https://community.sailpoint.com/t5/Professional-Services/IdentityNow-Rule-Validator/ta-p/166116

Please download and use the latest one when submitting rules for deployment otherwise you rule will get rejected for using the old version.

What I wanted to point out was that Generic Rules may start failing validation as it is doing much strict linting check for variables coming from transform which are not defined in the rule. You will need to add them to <Signature> tag for it to now pass validator.


You will see two inputs 

  • identity – this is the identity context which every cloud rule has access to but not predefined as input in the Generic Rule type.
  • identityEndDate – this is an input coming from a transform which is calling the rule

If I run this on the rule validator, it will fail with the following errors

As you can see – it couldn’t retrieve the definition for both the attributes 


You need to define them under the Signature XML tag so that the validator allows it through

As you can see the Signature tag is defined with Argument name and type. This will allow the rule validator to understand what they are. So the rule will now look like

Now the rule will pass

You are good to submit your rule now… 

Happy coding!!!

IQService: June 2022 Release – Auto Update Feature

So this snuck it without much fanfare but I was waiting for this feature (and just in time) as a client had just asked about it.

IDN is a great SaaS platform application which requires very little on-prem deployments. VA (Virtual Appliance) is obviously the key one but all the security and patching is managed by SailPoint itself. 

IQService is another must have tool for most clients as it is needed for AD Provisioning (among few other things it does for other connectors). So its generally deployed in nearly every client instance. One of the main thing about this is that it was not autoupdated and thus client needed to download the latest and do an update themselves. Although its not a lot (maybe twice a year) but still good to have a software which can patch itself to latest version. And of course this is optional and who don’t want this can choose not to install the feature but we highly recommend it.  

You DON’T need to give internet access to the IQService boxes to download latest updates. The latest IQService binaries are pushed to and are present on VA. This is via our existing process of update bundles being pushed to VA from cloud. At connector level, version is checked for IQService and if there is mismatch (new version available), latest version will be pushed out to UpdateService from the VA (As they already have line of sight to each other). Then UpdateService will coordinate and update local and then remote services.  It is quite simple process where in the respective services are stopped and binaries are replaced.

Article assumes you know what IQService is and where to deploy it. I will quickly give some commands on how to do so with the latest release. I will show various setups and quick commands to run to update them.

NOTE: You must have Provisioning License to use IQService. Talk to your CSM about it and make sure you are licensed to use it.

Documentation: https://documentation.sailpoint.com/connectors/iqservice/help/integrating_iqservice_admin/intro.html

Uninstall Previous IQService

Single Box install with Fallback Implementation

  • Installing TLS port only: 5060
  • UpdateService Port: 5062
  • User authenticating against IQService: abc\sailpoint
  • Software downloaded and extracted: C:\SailPoint\IQService\
  • Domain: abc.local
  • Certificates already configured and working for TLS (Check this post to do self sign cert for home labs)
  • Firewall is open for TLS port. You don’t have to open for 5062 as no remote IQService is connecting to it in this configuration. 
Check Status of Services
Check Status of UpdateService

IQService UpdateService

Multiple Box Install with Client Side Load Balancer

  • Installing TLS port only: 5060
  • UpdateService Port: 5062
  • User authenticating against IQService: abc\sailpoint
  • Software downloaded and extracted: C:\SailPoint\IQService\
  • Domain: abc.local
  • Certificates already configured and working for TLS (Check this post to do self sign cert for home labs)
  • Firewall is open for ports 5060 TLS on both servers and on primary server for UpdateService 5062 to accept incoming requests from other IQService boxes for update check.
  • Installing on two boxes: iqservice1.abc.local (considered primary) ; iqservice2.abc.local (considered secondary)
  • Box boxes can talk to each other for UpdateService
iqservice1.abc.local (installing UpdateService here)
iqservice2.abc.local (Going to connect to above UpdateService Instance)

That is it!!! you should have an IQService which can update itself and keep the environment updated with latest features and bug fixes.


IDN + Transforms + VS Code + Snippets = Lightning Speed #IDN101

Hiya Folks

Happy New Year!!!  

I have written a few posts before on how to write nested transforms and about a few new transform types available. But it still look like a tedious task when writing a transform – especially a complex one. It is as powerful as its confusing sometimes. I still don’t have full grip on the capabilities or the possibilities I can achieve without the need of rules. 

I love VS Code and especially its features and plugins. I use it extensively and also advocate the same to all my colleagues and clients for doing JSON and CSV files with IDN (and java coding obviously).

Few years ago one of my good mate Thomas Bui had shown me an interesting way to not need to remember syntax of each transforms while writing it. So credits to him.

Here I have built a package and hopefully show you how to deploy it in VS code and using the Snippet feature quickly write transforms with less errors.

It’s pretty simple. View the video I have made in VS Code (Works on Windows / Mac) . Please click on the gif to enlarge it. The embedded one is not rendering properly for some reason.

You will see how quickly I wrote a firstValid transform and replaced few lines with accountAttributes transforms (nested) and created a “Get New Dept” Transforms in couple of sec.

Steps are as below

  1. Open “Configure User Snippets” in VS Code Preferences
  2. Click on “New Global Snippets File”
  3. Call it say “transforms”
  4. In the file opened, replace the entire content with below code snippet
  5. Save and close the file 
  6. Now start typing the name of the transform (e.g. firstValid) and it will show up.
  7. Press Enter and it will show you the code

That’s it

Hopefully this was helpful and makes it easy for you to write transforms for IDN. Feel free to expand the snippet by adding your own shortcuts of complex transforms or code which you use often and feel free to share it below or the article