Centralized property store for transforms and rules

Content Community Blog
, ,
1

Tutorials-Blue
Tutorials-Blue2401×1354 211 KB

In the Identity Security Cloud, data transforms are designed to convert data from one different format to other. In certain cases, these transforms necessitate the inclusion of static values(hard coded values). For instance, when generating an email, it may be required to concatenate “firstname”, “lastname”, and a predefined hardcoded value suffix such as “[email protected]”. Incorporating hardcoded values into transformations becomes more complex as the number of such values increases, posing challenges to their effective maintenance.

Utilizing a centralized property store enhances administrative efficiency, fosters team collaboration, increases flexibility, and improves migration and maintainability. There are two approaches :

  1. Use a lookup transform as property file.
  2. Using the source as a property store.

You can watch a video presentation on this topic, or continue reading the blog post.

Use a lookup transform as property file

In this approach, we use the transform of type lookup and store all our configurations centrally. In the following illustration, the property lookup serves as a transform that retrieves the “value” corresponding to the input “key”.

You can utilize the property lookup transform within the main transform by using a “reference transform”. This approach eradicates the need for hardcoded value(s) in the main transform by invoking the property lookup transform.

image
image1375×553 71.9 KB

Property lookup is highly effective when dealing with a single environment. However, when managing multiple tenants, it becomes necessary to adjust the values according to the requirements of each environment. For example, when migrating the transform from the development environment to the production environment, certain values may need to be replaced to align with production requirements. With this consideration in mind, we can improve the previous version by implementing one property lookup transform per environment and then invoking the appropriate transform based on the current environment.

Our new transform, Get property value by key necessitates a property key as input and returns the corresponding “property value” based on the current environment.

Note: Get Environment transform is a static transform, which has to be configured with appropriate value to be returned. For instance, configure static value as “development” for dev tenant and prod for production tenant as per you need.

image
image1002×732 70.1 KB

Property Lookup

{
    "name": "Properties Development",
    "type": "lookup",
    "attributes": {
        "table": {
            "IN": "OU=USRS,OU=IN,DC=seri,DC=sailpointdemo,DC=com",
            "SG": "OU=USRS,OU=SG,DC=seri,DC=sailpointdemo,DC=com",
            "GB": "OU=USRS,OU=UK,DC=seri,DC=sailpointdemo,DC=com",
            "BE": "OU=USRS,OU=BE,DC=seri,DC=sailpointdemo,DC=com",
            "US": "OU=USRS,OU=US,DC=seri,DC=sailpointdemo,DC=com",
            "FR": "OU=USRS,OU=FR,DC=seri,DC=sailpointdemo,DC=com",
            "CA": "OU=USRS,OU=CA,DC=seri,DC=sailpointdemo,DC=com",
            "adDefaultOu": "OU=USRS,OU=DEFAULT,DC=seri,DC=sailpointdemo,DC=com",
            "Employee": "A",
            "Contractor": "C",
            "Vendor": "C",
            "Robot": "R",
            "cost_center_prefix_for_employees": "AAY22",
            "cost_center_prefix_for_contractors": "CAY01",
            "ad_upn_suffix": "@sailpoint.ad.demo.com",
            "mail_suffix": "@sailpoint.com",
            "prism_associate_type": "1",
            "prism_contract_type": "2",
            "prism_vendor_type": "3",
            "prism_date_format": "MM-YYYY-dd",
            "badge_date_format": "YYYY/MM/dd",
            "serviceNow_date_format": "MM-dd-YYYY",
            "serviceNow_time_format": "hh:mm:ss",
            "servcieNow_user_domain": "sailpoint.ad.demo.com",
            "default": null
        }
    },
    "internal": false
}

Get Environment

{  
    "name": "Properties Get Environment",
    "type": "static",
    "attributes": {
        "value": "development"
    },
    "internal": false
}

Get property value by key

{    
    "name": "Properties Get Value by Key",
    "type": "lookup",
    "attributes": {
        "input": {
            "type": "reference",
            "attributes": {
                "id": "Properties Get Environment"
            }
        },
        "table": {
            "development": {
                "type": "reference",
                "attributes": {
                    "id": "Properties Development"
                }
            },
            "sandbox": {
                "type": "reference",
                "attributes": {
                    "id": "Properties Sandbox"
                }
            },
            "production": {
                "type": "reference",
                "attributes": {
                    "id": "Properties Production"
                }
            }
        }
    },
    "internal": false
}

This concludes our first approach. Implementing a single centralized property lookup per environment aids in centralized property management and mitigates the need for hardcoded values in multiple transforms.

Use source as property store

In this approach, you have the flexibility to store your properties (key-value pairs) either in a delimited file or in a JDBC database or any other source as per the requirement.

  1. Begin by creating a source, which can be either a delimited file source or a JDBC source, depending on your preference for property storage. Then, configure the account schema to map the “key” from the source attribute to “Account ID”, and map the “value” to “Account Name”.
  2. Aggregate the data from the source.
  3. Create a generic cloud rule to retrieve the “value” from the property source.
  4. Develop a transform of type Rule and provide the input (key) to the rule. The output of the rule, which corresponds to a property value from the properties source, will then be returned to the transform.

image
image1286×635 78 KB

Delimited source account schema

{
    "nativeObjectType": "User",
    "identityAttribute": "key",
    "displayAttribute": "value",
    "hierarchyAttribute": null,
    "includePermissions": false,
    "features": [],
    "configuration": {},
    "attributes": [
        {
            "name": "key",
            "type": "STRING",
            "schema": null,
            "description": "The unique identifier for a  property",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        },
        {
            "name": "value",
            "type": "STRING",
            "schema": null,
            "description": "Property value",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        }
    ],   
    "name": "account",
    "created": "2024-03-30T23:34:34.658Z",
    "modified": "2024-03-30T23:37:19.718Z"
}

Rule Transform

{
    
    "name": "Properties Get Value By Key using Rule",
    "type": "rule",
    "attributes": {
        "name": "Get Property Value By Key V1"
    },
    "internal": false
}

Generic Cloud Rule

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule name="Get Property Value By Key">
  <Description>

</Description>
  <Source><![CDATA[


String applicationName = "Properties [source]";

String input = input;


public String getPropertyValueByKey (String key) {
  return idn.getAccountAttribute(applicationName, key, "value");
}

return getPropertyValueByKey(input);

  ]]></Source>
</Rule>

This concludes our second approach. Using a source as as a centralized property store not only useful for transforms but also for the cloud rules. Utilizing it within cloud rules offers its own advantages. There’s no need to request cloud rule deployment; instead, if there’s a need to change a value, it can simply be modified in the property store. During the next execution, the system will automatically incorporate the latest value. This approach facilitates cost savings by eliminating the need for cloud rule deployment requests.

1 Like