AD Source another attribute reference and reformat transform

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

I have a use case where the client wants to add a value to only the IDN attribute as we cannot write to AD yet. This is so we can then correlate the elevated account to the master account of the user. I wrote the below transform to add the create provision policy, on the source but I cannot get it to save to commit to the tennet. Can i get a 2nd eye,

Example -

Elevated Account - ADM_abcd
Action - need to add this “DisplayName” entry attribute to the empty IDN “accountOwners” field .as well strip every starting at the _ before so the outcomes.as below.

Output: abcd

{
    "name": "Acount_OwnerName_Transfom",
    "type": "static",
    "attributes": {
        "value": "$displayName"
    },
    {
        "type"::"split",
    "delimiter":"_",
    "index": 1
},
}

I am sure this will help a ton of people so please once solved use as need and don’t forget to give credit where credit is due

Thanks all

2

Hello,

Are you attempting to use this transform on an attribute mapped in an Identity Profile?

Are you getting an error message

3 
{
  "attributes": {
    "input": "$displayName",
    "delimiter": "_",
    "index": 1,
  },
  "type": "split",
  "name": "Acount_OwnerName_Transfom"
}

Try this perhaps.

(Make sure the original displayName attribute mapping is above this one in the list)

4

Hi @Swegmann i have a IDN attribute that was created call “Account Owner” it has no reference to any source but IDN. My goal is to add the transform to the policy of AD to take the display name "ADM_123 and clean it up and place as a string in the "Account Owners attribute for us to then use as a correlation key for this account to the master user account. I have been told i cannot use user Identity profile which would have made this 1000 times easier, so I am trying this route of doing it on the create policy instead on the source then the identity profile.

5

I’m not sure why you wouldn’t be able to use the identity profile? Mapping attributes directly from IDP to source provsioning policies are usually the smoothest way of developing if you ask me. Of course, you might not always be able to do this for every attribute, but for the one above I think should work just fine within Identity Profile, try it out!

1 Like
6

Sometimes you just have to go with what the client says

7 
{
    "name": "Account_OwnerName",
    "transform": {
        "attributes": {
            "input": {
                "attributes": {
                    "name": "displayName"
                },
                "type": "identityAttribute"
            },
            "delimiter": "_",
            "index": 1
        },
        "type": "split"
    },
    "attributes": {},
    "isRequired": false,
    "type": "string",
    "isMultiValued": false
}

If you’re gonna map the attribute directly on the Source Provisioning Policy, try something like this. (change attribute name to whatever your use-case)

You can use the PATCH API to add it to the Create Prov-Policy:

URL:

{{baseUrl}}/v3/sources/:sourceId/provisioning-policies/CREATE

Payload:

  {
    "op": "add",
    "path": "/fields/0",
    "value": {
    "name": "Account_OwnerName",
    "transform": {
        "attributes": {
            "input": {
                "attributes": {
                    "name": "displayName"
                },
                "type": "identityAttribute"
            },
            "delimiter": "_",
            "index": 1
        },
        "type": "split"
    },
    "attributes": {},
    "isRequired": false,
    "type": "string",
    "isMultiValued": false
}
8

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