GET /api/rule/list

[colin_mckibben]

There are two ways to get rules.

Get rules via CLI

The latest release of the CLI (2.1.4) allows you to list rules from your tenant.

Get rules via API

The replacement for this endpoint is to use the SP Config API to export rules for your tenant.

https://developer.sailpoint.com/idn/api/beta/sp-config

This is a three step process.

1. Initiate a configuration export using https://developer.sailpoint.com/idn/api/beta/export-sp-config. Use the following request body payload to export rules.

   {
     "description": "Export all available rules",
     "excludeTypes": [],
     "includeTypes": [
       "RULE"
     ],
     "objectOptions": {}
   }
   

   Save the jobId that is returned for use in the next two steps.

2. Check the status of the export job using https://developer.sailpoint.com/idn/api/beta/get-sp-config-export-status. You will need to provide the jobId from the last step in the URL of this endpoint. Depending on the size of data that needs to be exported, this can take a few seconds to a few minutes. You will need to wait for the status to show COMPLETE before you can download the results.

3. Download the results using https://developer.sailpoint.com/idn/api/beta/get-sp-config-export, inserting the jobId from step 1 into the URL. This will return a JSON response of all the rules in your tenant.

Get rules via Config Hub

Using Config Hub, you can export rules from the user interface.

[adunker (Alex Dunker)]

How would we be able to get a cloud rule name / ID to attach to sources? Would the expectation to be to use SP-Config to initiate an export of rules and the get an name / ID from there? That should work fine - just annoyingly cumbersome compared to having an endpoint for cloud rules.

[jalexand]

We are currently going through an IDN implementation. This endpoint is crucial to troubleshooting cloud rules. Otherwise, we cannot view the rules to check the logic as far as I know. It’s rough enough we have to submit a ticket every time they need updated, but being unable to view them is going to be a big roadblock.

Is there another method of viewing the script the cloud rule is running? Can the deprecation simply be pushed until the replacement is available?

[jallen (James Allen)]

I agree, this feels like quite an important endpoint for troubleshooting rules. The description is very clear to me, when you say “There will not be a public replacement available before March 31st” does that mean that there will be a replacement on March 31st or that there’s no planned replacement or ETA for a replacement? As @jalexand says, it’s already a pain that we have to pay extra to get these updated, would be even worse if we had to pay just to see what the rules look like.

[colin_mckibben]

Good news. Our SP config API can export all rules, including cloud rules. I have update the first post in this topic to demonstrate how to do this.

[jalexand]

Excellent, I’ve confirmed I was able to retrieve the rules. It’s not as streamlined, but it solves the ask nonetheless. Thank you, Colin!

[akasper (Alf Kasperczyk)]

Umm, HELP!! - This does NOT return any data, it just starts a background job.

Can you please advise how to update the ruby I/O TOOL (idnio-2.3.4b) to manage this?? (rules.rb) (We’ve been relying on this and have history for 3+ years as our fortnightly backup.)
My ruby knowledge is only as far as I can google - or can AI rewrite it for us??

#
# Exports Rule configurations.
#
def self.export( directory )

response = IDNAPI.get( "#{$url}/cc/api/rule/list", $token )

case response
when Net::HTTPSuccess

 rules = JSON.parse( response.body )

etc…

[colin_mckibben]

@akasper

Umm, HELP!! - This does NOT return any data, it just starts a background job.

Sorry about that. You are correct in that this a three step process. I have updated the post to describe each step needed to get the rules, as well as how to do this using Config Hub.

You will need to update your ruby script to follow the three step process mentioned above. I too would need to google the right ruby code but here is some pseudo code to help you update your script. This is not ruby code, just an example of the steps you would need to take in your code to accomplish exporting rules. You’ll need to google the correct ruby code to make this work.

payload = {
  "description": "Export all available rules",
  "excludeTypes": [],
  "includeTypes": [
    "RULE"
  ],
  "objectOptions": {}
}
# initiate the export job for all rules
response = IDNAPI.post("/beta/sp-config/export", payload)
jobId = response["jobId"] # Save the jobId

# Check the status of the job every 5 seconds until it is complete
exportStatusUrl = "/beta/sp-config/export/" + jobId
while (JSON.parse(IDNAPI.get(exportStatusUrl).body)["status"] != "COMPLETE")
    wait(5) # wait 5 seconds

# Get the results
exportDownloadUrl = "/beta/sp-config/export/" + jobId + "/download"
response = IDNAPI.get(exportDownloadUrl)
rules = JSON.parse(response.body)

[reklawttocs (Scott Walker)]

Hi Colin.

The Visual Studio Code Extension for IDN included listing Rules (though just connector rules for whatever reason). We use that tool a large amount for our ongoing enhancements as we flesh out our IDN implementation from last year (2023). To your knowledge is the maintainer of that tool incorporating the new approach for Rules ?

[colin_mckibben]

T

@reklawttocs

The Visual Studio Code Extension for IDN

The VS Code Extension is a community tool maintained by @yannick_beot .

[reklawttocs (Scott Walker)]

Right, thanks. And I likely answered my own question as it looks like the VS Code rules management uses the Beta Connector Rule Managment APIs, so it should still be ok. And that explains why it just shows the Connector rules and not any Cloud rules.

[reklawttocs (Scott Walker)]

One key difference I note in the new approach to retrieving Rules is that the beta/sp-config/export API response does not seem to include any of the default rules vs. the /cc/api/rule/list API which included the default/demo rules. i.e. only rules which have been customized in the target tenant are returned by beta/sp-config/export.

Pros and Cons to this difference. Is this on purpose ?

[colin_mckibben]

@reklawttocs

One key difference I note in the new approach to retrieving Rules is that the beta/sp-config/export API response does not seem to include any of the default rules vs. the /cc/api/rule/list API which included the default/demo rules. i.e. only rules which have been customized in the target tenant are returned by beta/sp-config/export.

Possibly just an oversight. I don’t think it would be intentional to leave out rules.

[yannick_beot]

@reklawttocs
Currently, the VSCode plugin can export all rules through the SPConfig.
I have just tested and by selected all rules, cloud rules will also be exported.

Actually, I just learned from Colin’s answer that the SPConfig could be leveraged to get the cloud rules.

Not sure what I can do more.
Cloud rules will not be “editable” as connector rules.
Feel free to create an issue as an enhancement request and to write your expectation, expected behavior and all.