Can I use the IdentityAttribute transform as value for provisioningCriteria in Access Profiles?

[eabedrapo1 (Elisa Abedrapo)]

Hello,

We have multiple accounts in a source, but only one is the primary one for each identity. We captured the username for that primary account as an attribute in the identity profile.

We need to assign access profiles to the primary account but the “Multiple Account Options” in the UI only allows attribute matches to a static pattern (equals / not equals / contains a static string).

I tried to use the API endpoint to customize the provisioningCriteria for said access profile in order to pass an IdentityAttribute transform to the “value” parameter, but it seems that input doesn’t work.

Is there any other way to build the matching condition that I can use under “Multiple Account Options”, so we can provision this access profile to the primary account in the target source?

Ref:

1. patch-access-profile | SailPoint Developer Community
2. Identity Attribute | SailPoint Developer Community

Thanks in advance for your help!

Elisa.

[schattopadhy (SHANTANU CHATTOPADHYAY)]

@eabedrapo1 you should have some conditions at account attribute to distinguish as shown below:

[eabedrapo1 (Elisa Abedrapo)]

Thanks Shantanu, I’d like to have a dynamic value instead of a hardcoded string.

I tried to use the access-profile API to modify provisioningCriteria using IdentityAttribute transform (whose result is a string), but not sure if that’s supported.

If this doesn’t work, how can I target accounts whose username == primaryUserName for each identity matching the criteria of the role that contain this access profile?

Thanks!

[mohammedfavazhrb (Mohammed Favaz S A)]

Hi @eabedrapo1 ,

I am not sure if it works but have you tried using $ symbol followed by the identity attribute technical name in the value field?

Thanks

[eabedrapo1 (Elisa Abedrapo)]

Hi @mohammedfavazhrb, this is my provisioningCriteria node:

    "provisioningCriteria": {
        "operation": "EQUALS",
        "attribute": "<accountAttribute>",
        "value": {
            "attributes": {
                "name": "<targetAttributeValueInIdentityProfile>"
            },
            "type": "identityAttribute"
        },
        "children": null
    }

Where shall I insert the $ sign?

Thanks for your help!

Elisa.

[vdivakar (Vaibhav Divakar)]

Hey @eabedrapo1 ,
Is there any attribute in target source by which we can decide if that is a primary account or not ?
e.g. if target source is Active Directory, and if there is an attribute called extensionAttribute1, which holds value True or False based on if it is primary account or not…

I am saying this because the multiple account criteria can only be applied on the target source attribute.
Even if what you are trying to do is achievable, its a cyclic condition that might cause issues in the system, because you are trying to compare account attribute value with identity attribute value, which has got the value from the same account attribute.

[mohammedfavazhrb (Mohammed Favaz S A)]

Hi @eabedrapo1 ,

I was thinking something like this. Not sure if it works

Also you can try this as well,

    "provisioningCriteria": {
        "operation": "EQUALS",
        "attribute": "<accountAttributename>",
        "value": {
            "input": {
          "attributes": {
            "name": "identity attribute name"
          },
          "type": "identityAttribute"
        }
        },
        "children": null
    }

Thanks

[eabedrapo1 (Elisa Abedrapo)]

@mohammedfavazhrb

I was thinking something like this. Not sure if it works

Hm! Interesting, I’ll try it out when I have some quiet time tomorrow. I’ll let you know how that goes.

If that doesn’t work, I’ll also try the suggestion for amending the transform into the provisioningCriteria configuration.

Thank you!

[eabedrapo1 (Elisa Abedrapo)]

Unfortunately we’re only able to read from AD, but we don’t have physical access to manipulate AD values (we could initiate a “sanitization project” with the team that manages that mess, but I would rather avoid that because it would take years to complete).

Our workaround to deal with these multiple accounts was to capture the primary sAMAccountName in the identity profile which worked to target some Okta applications that still rely on that AD source. First time I heard about “cyclic conditions” for this approach, could you elaborate further what risks do you see here?

Thanks Vaibhav!

[vdivakar (Vaibhav Divakar)]

I am just saying that, let’s say, you could use identity attribute with $ sign in the value section of Access Profile Multiple account,
Lets say you have captured “sAMAccountName” in an identityAttribute called “Account Name”. So you will use $accountName in the Multiple accounts section criteria.
Your criteria would be sAMAccountName Equals $accountName.

I am just saying that you are getting the sAMAccountName value in identity Attribute “Account Name” and also at the same time trying to compare that value with the AD Account Attribute “sAMAccountName”.

So, since we do not know which task SailPoint takes up first, taking account attribute value in identity attribute or compare the multiple account criteria, you might end up with error while assigning those access profile to primary account.
This is what I am imagining, assuming that you could use $accountName…

[eabedrapo1 (Elisa Abedrapo)]

@mohammedfavazhrb

I was thinking something like this. Not sure if it works

Hi @mohammedfavazhrb, this solution didn’t work, but I think it’s the closest I’ve reached. I’ll explore to resolve this via Workflows, but in the meanwhile I’ll mark your answer as the “Solution” for this thread.

Thanks for sharing your ideas though.

Have a great weekend!