Using non Identity Attribute in Rule Transforms

Identity Security Cloud (ISC) ISC Discussion and Questions
, , , ,
1

Hi everyone, I wanted to use the by default provided cloud rules to generate unique attributes like sAMAccountName and DN/CN. The issue I am facing is that one requirement for these is that the users first- and lastnames can contain special chracters which should be replaced (for example via replace transform).

The issue that I am facing is that when I want to use the cloud rules and give them a pattern with non identity attributes it doesnt work .

In this example I just used dummy values without really using any operation on the identity attributes beforehand to do a proof of concept, that using Attributes I define in the transform itself works, but it doesn’t work
[
{
“op”: “replace”,
“path”: “/fields/44”,
“value”: {
“name”: “sAMAccountName”,
“transform”: {
“type”: “rule”,
“attributes”: {
“name”: “Create Unique LDAP Attribute”
}
},
“attributes”: {
“cloudMaxUniqueChecks”: “50”,
“cloudMaxSize”: “20”,
“cloudRequired”: “true”,
“template”: “$(testLast)$(testFirst)$(uniqueCounter)”,
“testFirst”: “Max”,
“testLast”: “Mustermann”
},
“isRequired”: false,
“type”: “string”,
“isMultiValued”: false
}
}
]

Did I maybe do a mistake here or do I have my own cloud attribute generator rule to fulfill my requirements?

Thank you in advance!

2

Hello @fayadm ,

In order to remove the special/diacritical characters from the firstName and lastName, you have to get it done at identity attribute level only.

So, what you can do is:

  1. If you dont want to use the OOTB firstname and lastname identity attributes, create new once which lets say are named as : testFirstName and testLastName.
  2. On both the identity attributes, attach a transform in respective identity profiles which uses “decomposeDiacriticalMarks“. Refer a below sample.

Transform for testLastName identity attr.

{
  "name": "Test - FirstValid - LastName",
  "type": "firstValid",
  "attributes": {
    "values": [
      {
        "type": "decomposeDiacriticalMarks",
        "attributes": {
          "input": {
            "attributes": {
              "sourceName": "<AuthzSourceName>",
              "attributeName": "LAST_NAME"
            },
            "type": "accountAttribute"
          }
        }
      }
    ],
    "ignoreErrors": true
  },
  "internal": false
}

Transform for testFirstName identity attr.

{
  "name": "Test - FirstValid - FirstName",
  "type": "firstValid",
  "attributes": {
    "values": [
      {
        "type": "decomposeDiacriticalMarks",
        "attributes": {
          "input": {
            "attributes": {
              "sourceName": "<AuthzSourceName>",
              "attributeName": "FIRST_NAME"
            },
            "type": "accountAttribute"
          }
        }
      }
    ],
    "ignoreErrors": true
  },
  "internal": false
}
  1. Then, use this attribute in your custom Account Attribute generator cloud rules or OOTB rule - Pattern.

The above transforms will remove the special and diacritical characters from your firstName and lastName coming from Authz Source.

The above solution is on removal of special characters.

Now, lets move to your another question of how to generate the Unique SamAccountName, the approach you are using will not work as expected at all.

The best way is to use “Custom Account Attribute generator cloud rule“ only. Refer the below sample code.

Summary.

  1. Use identity attributes and transforms to remove diacritical characters from firstname and lastname
  2. Use Customer Account Attribute generator cloud rule to generator SamAccountName in which you can also perform uniqueness check if required.

If you want a more specific one, let me know.

Regards,

Rohit Wekhande.

3

Hi @fayadm I recommend reading up about Transforms (not Rules) at Transforms | SailPoint Developer Community

Particularly check the syntax definitions. For instance, you can’t just declare variables by adding them to the attributes section, see the use of Static Transforms.

I also strongly recommend the use of VSCode plugins for Transform testing.

4

Hi @rohit_wekhande WADR, it is considered best practice to only extend the Identity schema when absolutely necessary. As the OP use case can easily be achieved with nested transforms in the Source Provisioning profiles, that would be the preferred solution.