Configuration properties

Hi All,

I need help finding the best way to store configuration properties in IdentityNow that vary across different environments (development, staging, production). Ideally, I want to centralize all configurations for easy management and store them in version control to pull them automatically during deployment. It’s a daunting task to replace all configurations when migrating from lower to upper environments, and missing a rule or transformation function can cause production issues. Can you assist me with this?

Configurations examples:

  1. AD connector: upn suffix “sailpoint.com for prod” /“dev.sailpoint.com for dev” / “stg.sailpoint.com for stg”
  2. Exchange: Email Address suffix “@sailpoint.com”, “@dev.sailpoint.com”, “@stg.sailpoint.com
  3. Storing a list of OUs for some of the calculations in rules
  4. Generic prefixes for unique logic generators for different connectors based on business needs.
  5. There are numerous situations where it becomes necessary to store static data for computing account attributes or identity attribute values.

I can’t really speak to “storing” these properties, but there are a few tools that you should be aware of that help with promoting configurations between environments.

  1. SaaS Configuration is designed for backup and restore of tenant configurations, with limited support for migrating configuration objects to new tenants.
  2. There is a community built Terraform connector that can promote configurations between environments. GitHub - OpenAxon/terraform-provider-identitynow: Terraform provider for IdentityNow cloud-based access management product
  3. SailPoint is working on an improved version of SaaS Configuration that will expand upon its ability to promote configurations between environments. More details later this year.
2 Likes

I agree it’s a daunting task if you have too many objects to move, but we cannot generalize it too much without any manual intervention.

If planning to use powershell/SDK for migrating objects, one way i could think of was to use a standard properties file with key:value pairs. Your script will use APIs to get and create objects while referring the properties file and replace specific values as needed.

If you want something at IDN UI level, maybe you can import properties file into IDN as delimited file connector and each instance can be an account while each property you need will be part of your account schema. You then create specify identity attributes based on this to use within IDN.

1 Like

@colin_mckibben @sharvari thank you for sharing your thoughts.

I’ve been thinking about using a different source for properties.

Also, I’m exploring the option of storing additional attributes in the connector configuration. However, the downside is that seems it will not be able to read it in transformations, but it will be accessible in rules (in application sailpoint.object.Application).

For rules, A combination of connector attributes and terraform referred to by @colin_mckibben would help us to automate the deployment process.

For Transformations, Have to explore options to have one transformation function per environment with all static key/value pairs. All other transformations, retrieve the values from the static transformation.

Chiming in to ask about the community-built Terraform provider. First off, this is awesome and looks like it will meet with some of our needs. Is there any intent for SailPoint to publish an official Terraform provider for IDN in the future?

Welcome to the developer community Michael.

SailPoint doesn’t have any plans to release a terraform provider at this time. However, SailPoint is working on Configuration Hub, which is going to be an improved UI mechanism for backing up, restoring, and promoting configurations between IdentityNow tenants. It’s not terraform, but it will work similarly to it.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.