Is there anyway to skip account provisioning for few entitlements and allow provisioning for other

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

Which IIQ version are you inquiring about?

Version 8.2

Share all details related to your problem, including any error messages you may have received.

In our solution, we are using CREATE provisioning policy for Active Directory. So, whenever any AD group (entitlement) is assigned to an identity, CREATE provisioning policy is evaluated and AD account is created.
We need a solution, where AD account should be created only for birth right roles/entitlements. If there is no AD account for a user and the AD role/entitlement is requested by a user which is not a birthright role/entitlement, then AD account should not be provisioned. However, since we have CREATE provisioning policy, AD account gets created if there is no account already present.

Customer scenario: New user onboarded in SailPoint and AD account is provisioned. The user does not login using the AD account and hence the account is disabled and moved to archive OU by AD disabler script scheduled on Active directory after a certain period of time. (Note: Current SailPoint implementation does not read the archive OU, so no AD application link is present for the identity once the account is moved to archive by disabler script). Now the user is back and request for a role, and since the AD account is not present, CREATE provisioning policy creates a new AD account. So, we need to restrict this. Is there anyway we restrict the creation of AD account based on entitlements / roles requested in “AD Before Provisioning Rule” ?

2

You can do that - in before provisioning rule you have account request with create set as operation and attribute requests for memberOf attributes.

You can in this rule just inspect if operation is create and memberOf contains any of the restricted entitlements you can just remove this account request from provisioning plan.

If you do so - IIQ will not create account.

4

@milinaphalke i don’t think we have any API.

but you can try to make method like below. it will return all groups that are part of that role. you can check whatever you need.

Syntax might you need correct, but logic should be around that.

public List getgroupsfromRole(SailpointContext ctx, List roles) {
List groups = new ArrayList();
for(String role : roles) {
   Bundle roleObj = ctx.getObjectByName(Bundle.class, role);
   roleObj.load();

   List reqRoles = roleObj.getRequirements();
   for (Bundle itR : reqRoles){
	List p = itR.getProfiles();
        for(Profile pr : p) {
		  List listF = pr.getConstraints();
          int size = listF.size();
          for(int i = 0; i < size; i++) {
            if(listF.get(i) isntanceof LeafFilter) {
              LeafFilter filter = (LeafFilter) listF.get(i);
              Object value = filter.getValue();
              if(value instanceof ArrayList) {
                ArrayList listEnt = new ArrayList();
                listEnt = (ArrayList) value;
                groups.addAll(listEnt);
              }
            }
          }
        }
    }
}
 return groups;
}

thanks,
Pravin

5

Hello Pravin,
Thanks for looking into the issue.
The challenge is that in BeforeProvisioning Rule we don’t have the roles information.
We just have the memberof attribute values (AD group values) in the plan.
Hence, we need some way to find the parent role of any entitlement (AD group) and then check if the role is birth right role or not.

Thanks & Regards,
Milina Phalke

6

@milinaphalke Normally we maintain birthright role in some custom file like joiner custom file. if not then you can maintain one custom file Or Create a method to get all Birthright role, it should be one filter and you will get all B Roles. then you can check in before provisioning rule.

let us know, will check other options also.

7

Thank you @pravin_ranjan.
Yes, we also have a custom file having birth right roles defined.
Challenge is in the before provisioning rule, we don’t get the roles in plan, we are just getting the memberof attribute with AD group values.
So not able to back track to roles from memberof AD group values which are entitlements of the role.

We may need to define another custom file having entitlements (AD groups) which are part of birth right roles ?

Thanks & Regards,
Milina Phake

8

@milinaphalke is this not your requirement “if entitlement /memberof group is part of birthright role or not” ?

if yes, let’s see if below logic works ?

  • you have memberOf from plan
    • here you can call generic method to get all groups that are part of BR Roles ( this method should read role from custom file - method provided in thread)

Now you have both groups list, one from plan and one from roles. i think you can easily check if groups from plan is part of groups from roles or not.

Sorry if i miss your requirements.

9

Thank your @pravin_ranjan .
We have plenty of entitlements as part of birthright roles for different user types and their subtypes and the same entitlement can be requestable for some cases.
We will give a try on the approach suggested.
Thanks & Regards.
Milina Phale

10

@milinaphalke

Is your birthright role provisioning happens via Life cycle event and does this provisioning done via LCM provisioning workflow or provisioner API? I wanted to understand does this have a tracking identity request ID

11

Hi @iamksatish
Provisioning is done via LCM provisioning workflow and there is identity request ID for tracking.
Thanks & Regards,
Milina Phalke

12

@milinaphalke
Can you try printing the plan xml in your before provisioning rule done via Birth right role

I believe your plan xml will have either have the Identity Request ID or provisioning transaction ID from which you can actual traverse back to that request and see if thats actually birthright role request part of your configurations then if that satisfies you can have conditions accordingly

We have done a similar check in one of our case but again it depends on your implementation as well, so I would suggest you to print the plan xml and share if possible here

Sample code which we used.

 Map planAttr=plan.getArguments();
      String reqID="";
      if(planAttr!=null &amp;&amp; planAttr.get("identityRequestId")!=null)
      {
        reqID=planAttr.get("identityRequestId");
      }
13

Thank you @iamksatish !
Yes, identityRequestID is present in the plan.
Will try out the solution suggested by you.
Thanks & Regards,
Milina Phalke

14

@milinaphalke
Sure , I believe this should resolve your issue

Please test and let me know if still any help required.

15

Hi @iamksatish
I have tried out the following:

  1. Retrieved the identityRequestId.
  2. Created an IdentityRequest object by lookup of the ID.
  3. Retrieved the IdentityRequestItems. Here I could see one of the items as assignedroles as shown below sailpoint.object.IdentityRequestItem@19a93b59[id=7f0000018fb8131381903b100cff75ee,name=assignedRoles]
  4. Here I don’t see the role values and neither I see any way to retrieve the same.
  5. I am trying out few things like getting the ProvisioningPlan using IdentityRequestItem and then call getIIQAccountRequest() and then try to retrieve the roles from it.
    Can you please confirm if I am going in the right direction.

Thanks & Regards,
Milina Phalke

16

@milinaphalke
Try this, this should help you

   IdentityRequest idrObj = context.getObjectByName(IdentityRequest.class, requestId);
    String roleName="";
    List idrItems=idrObj.getItems();
    for(int i=0;i&lt;idrItems.size();i++)
    {
      if("assignedRoles".equalsIgnoreCase(idrItems.get(i).getName()) &amp;&amp; "IIQ".equalsIgnoreCase(idrItems.get(i).getApplication()))
      {
        roleName=idrItems.get(i).getValue();
        break;
      }
    }

You can actually instead of break, add all the roles to a list and check if any of the requested roles are part of configured Birthright roles

17

Hi @milinaphalke

You should use Policy violations for this.

Advanced Policy violation is best for this requirement.

If user submits request for any AD Group, if user doesn’t have AD account already then prevent the request.

Thanks
Krish

2 Likes
18

Hello @milinaphalke
Please check if any of the following options works for you:

Option 1: If you want to allow users to request and provision AD group access, even if the link is not present but they have an account on AD:

1. Segregate your birth right roles for AD as below. 
2. Basically Birthright Role 1 to just create AD account (just refer the AD application on the provisioning policy of role) from Joiner
3. Birthright role 2 to assign the birth right AD groups. With your existing logic criteria add one more logic which look for if user have an existing AD account. This will prevent AD account creation from this role. It will only provision birth right groups if they have an account (handled in step 2).
4. In your before provisioning roles look for if in your account request have any group/entitlement then it's a Update else it's a Create.

Option 2: Prevent users to submit AD groups request if there is no AD link on the profile:

Here I am assuming that birth right provisioning is automated from joiner and all the active user will have AD account with birth right groups.
1. Create a RequestObjectSelector rule and add to the Quicklink (Everyone or selfservice based on your requirement ) > What can members request? > Entitlements
2. In the RequestObjectSelector rule you can add a logic to only show the AD entitlement if the selected user have AD application link.
This will prevent user to even see the AD based groups, if there is no AD application link on their profile in access request catalog.
3. Once user is back and moved to the active OU which is retrieval from your AD. They will be able to see the AD entitlements for request automatically.

19

Thank you @iamksatish !
yes, this solution worked.

21

Thanks @ab_sailpoint !
Will check out the solution.

22

Thanks @MVKR7T
Will check out the solution.