Reference a provisioning plan attribute in my provisioning policy

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

Hello,
I an making a create provisioning policy and I have an attribute called second factor that forces MFA on users in the applications. I only want to force MFA on account create for specific values of entitlement requested.
For example:

  • Identity A requests Access profile 1, during the creation I have to put the value “SMS” in the MFA field for the account.
  • Identity B requests Access profile 2, during the creation I have to put the value “NONE” in the MFA field for the account.

I have the create account with “ENT” request checked in my we service connector source, and field containing the entitlement is called “accessProfile” in the provisioning plan. I am trying to see if I can reference the entitlement field in my create account provisioning policy using a lookup and having my input as $plan.accessProfile.
I am suggesting this syntax because we have a transform that references to the identity as follows $identity.getManager().getAttribute(\"email\") and I am trying to see if there is something similar for the provisioning plan.

I also know that this can be handled easily with a before operation rule, I want to see if we can do that in the provisioning policy because it would be easier to modify if more entitlements get added in the application later on.

Regards,
Nadim

2

That is a good thought Nadim. It will be great if it works.

We don’t know if plan will be available in Provisioning Policy form.
If available, does it have Access Profile ?

Who knows ? If it is IIQ then you can print in LCM workflow and see the data rite.

You can test and let us know.

If it won’t work, as an alternative you can go for Before Provisioning Rule.

Yes it is correct that, you need to update Before Provisioning Rule every time if your requirement changes. You can create an Identity Attribute, so that no need to touch Rule for every time requirement changes.

  1. Store entitlements in attribute as CSV, I know this is not a good approach. Using Identity attribute as a custom object in IIQ.
  2. Create a Transform to evaluate this Identity attribute, if user has any of these entitlements then return True or False. Enable this in sync, but this won’t work at the time of account creation as user doesn’t have entitlements yet.
3

Hello Krishna,

I am not sure what syntax I should be using to reference the provisioning plan in my provisioning policy. If you have any suggestion I would gladly take them

As for your Idea of creating an Identity Attribute, this solution does not suit us because we need to know at the time of creation only if we have to enable MFA or not. and this value will not be modified later on

4

I don’t believe the documentation has any information on using a transform to reference attribute requests in the initially built plan from what was requested in the access request. However, you technically can use Account Profile Attribute Generator Rules which is essentially a FieldValue rule in IdentityIQ. In that rule, there is an accountRequest argument passed in where you could access the attribute requests which already exist from the access request. Assuming that same argument is passed into the Account Profile Generator Transforms, you may be able to access it in a Static transform with Velocity. I think we would need more input from SailPoint if this would actually work.

Alternatively, you could use the Profile Attribute Generator Rule which should have the accountRequest passed to it that you could inspect (although the documentation does not say it is passed in :smiley:)

i.e.

List ents = accountRequest.getAttributeRequests("EntitlementAttributeName");
//your logic here
5

You can just try $plan and see what value it holds from Account activity, we can see Account Request rite. If it is there then you know which value to pull.

If you need to have at the time of creation only then as I mentioned, I will create an identity attribute which has a static or concat transform that returns comma separated values.

For example,

Attribute Name: MFA Access

Transform:

{
  "attributes": {
    "value": "Access1,Access2"
  },
  "type": "static",
  "name": "Static Transform"
}

In Before Provisioning Rule, I will extract Identity Attribute and use these values to check the conditions in defining MFA yes or no.

Later point of time, if you need to add one more access then just update this Transform, no need to touch the BP Rule.

What @patrickboston mentioned is also works, but those are also cloud Rules which needs to updated if requirement changes same as implementing entire logic in BP Rule.

I would go for the static transform approach to not depend on cloud deployments every time requirement changes.

6

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