Happy New Year Folks!!!
Hopefully this year is better than previous and as always.. stay safe!!!
Anyone who would have worked with IDN would have used or encountered rules. They are wildly used and inevitable component of any deployment to achieve your requirements. So you must be well aware that no client, partner and in fact most of internal SailPoint PS/ES also don’t have access to deploy their rules to their tenants. These rules are reviewed by a specialist team within ES and they upload it to the tenant. There are some very good reasons for doing so due to the SaaS nature of our product and IDN architecture.
There is a lot of work being done to reduce dependency on rules and also a lot in pipeline to make this process simpler. This also does increase our own workload on tickets, review and deployment and we want to reduce it too as IDN has exploded into the world in past few years and new tenants onboarding everyday.
Current Process of Rule upload
- Send it to SailPoint as an ES ticket. Support will forward it to ES if not as rule review is a billable task.
- Rule review is done and uploaded to tenant.
- Ticket is responded to and closed after confirmation.
To make this process faster and seamless do follow some best practices
- Read the whole rule guide .
- Run the rule validator and send us the output of it.
- Make sure the naming convention is followed for the rule names
- Best to keep the same structure and print of code so it’s easy to see the difference in git for us.
Once the rule has been uploaded to your tenant, there might be a need of additional steps to attach the rule to your source (depending on the type of rule). Once the rule is uploaded you will need the RuleID for some of the rules (mentioned below) to attach it to your source. Please ask the ES person for it if not already given. It will be a long random GUID. We use Postman to execute the API calls but feel free to use your choice of client.
There is a great guide written internally by Neil McGlennon but I am expanding on it.
Few common things found below
- {ruleID}: This is the rule ID generated after rule is uploaded to your tenant. Ask ES for it if not given already
- {Rule Name}: This is the name of your rule.
- {id}: This is the externalID of the source you want to attach it to. It is a long GUID and NOT the shortID found in the URL. You can obtain it by few different methods but simplest is by doing a GET /cc/api/source/get/{shortSourceID} where “shortSourceID” is the ID of the source found in the URL when clicking on it in the tenant.
- All the API calls use https://{tenantname}.api.identitynow.com/ as the URL (before /beta/…)
- All of these examples use a PATCH for a partial source update, however PUT operations will work too, as long as the entire source object model is provided.
- For the PATCH operations, a op key has to be provided. For new configurations this is typically set to add as our example shows, however they can be any of the following:
- add – Add a new value to the configuration. Use this operation if this is the first time you are setting the value, i.e. it has never been configured before.
- replace – Use this operation to change the existing value. Use this operation if you are updating the value, i.e. you want to change the configuration.
- remove – Removes a value from the configuration. Use this operation if you want to unset a value.
Beware! Removals can be destructive if the path isn’t configured properly. This could negatively alter your source config!
This rule doesn’t need to be attached via API as it can be seen via UI under Attribute Mappings
This rule doesn’t need to be attached via API as it can be seen via UI under Create Profile for any source which has one.
This rule doesn’t need to be attached via API as it can be seen via UI under Create Profile for any source which has one. (as above)
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json [ { "op":"add", "path":"/accountCorrelationRule", "value":{ "type":"RULE", "id":"{ruleID}", "name":"{Rule Name}" } } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json [ { "op":"add", "path":"/managerCorrelationRule", "value":{ "type":"RULE", "id":"{ruleID}", "name":"{Rule Name}" } } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json [ { "op":"add", "path":"/beforeProvisioningRule", "value":{ "type":"RULE", "id":"{ruleID}", "name":"{Rule Name}" } } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json Note: Because the value is a list, all available AfterCreate, AfterModify, BeforeCreate, and BeforeModify rules will need to set in the same list. [ { "op":"add", "path":"/connectorAttributes/nativeRules", "value":[ "{Rule Name 1}", "{Rule Name 2}" ] } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json [ { "op":"add", "path":"/connectorAttributes/buildMapRule", "value":"{Rule Name}" } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json [ { "op":"add", "path":"/connectorAttributes/jdbcProvisionRule", "value":"{Rule Name}" } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json Note: Replace * with the index of operation. For example 0, 1, 2, etc. [ { "op":"add", "path":"/connectorAttributes/connectionParameters/*/beforeRule", "value": "{Rule Name}" } ] |
|
|
PATCH /beta/sources/{id} Content-Type: application/json-patch+json Note: Replace * with the index of operation. For example 0, 1, 2, etc. [ { "op":"add", "path":"/connectorAttributes/connectionParameters/*/afterRule", "value": "{Rule Name}" } ] |
Once any of the rule is attached, it’s ready for use immediately by the source or profile.
Hopefully this covers all rule types and if you have any issues with attaching a rule in your tenant, please feel free to reach out to me or to Support / ES team.
Like this:
Like Loading...
