Assignment Logic Failing within Role

Identity Security Cloud (ISC) ISC Discussion and Questions
1

We have a role with assignment criteria limiting membership, but all identities are being given the role upon applying changes . For example:

Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 1
OR
Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 2
OR
Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 3

In this case, Some AD Groups 1,2, & 3 encompass most identities, leaving only a small remnant to be assigned this role. Yet, IDN appears to be ignoring the logic and assigning the role to all users, including those in the above Some AD Groups 1,2, & 3.

We have rebuilt the role completely, but the sweeping assignment continues.

We have not encountered this before. Is this a known issue?

2

Hey @jnymeyer,

Thanks for posting in the forums!

If I’m understanding your query correctly, then your logic is correct, assuming all of these are inside different criteria groups.

Based on the format of your post, I would wager they are all inside one criteria group.

Please split them up into different criteria groups and let me know if that resolves your issue.

4

Hi Luke,

Thank you for your response. These AD groups with OR operators were all within one criteria group. The reason for this is that we needed to leverage an additional criteria group containing OR operators with an AND operator between the two criteria groups.

Here is what we were attempting:

(Criteria Group A)

Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 1

OR

Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 2

OR

Type: Entitlement; Source: AD; Operation: Does Not Equal; Entitlement: Some AD Group 3

AND

(Criteria Group B)

Type: Identity Attribute; Name: LifeCycle State; Operation: Equals; Value: Active

OR

Type: Identity Attribute; Name: LifeCycle State; Operation: Equals; Value: Prehire

It seems to me that this should produce a result where the role assignment restricted to all Active and Prehire users except those in Some AD Groups 1,2 & 3.

Am I misunderstanding how IDN handles this logic configuration?

Thanks.

5

@jnymeyer The Criteria Group A will work similar to how Group B is working. The user can be in either Active OR Prehire to make the group condition True.

For Group A, if any of the 3 conditions is True then then entire Group is True. Thus any user that does not have all 3 entitlements will be part of this group.

Examples:
John has none of the AD groups: The first condition is met (technically all 3) and the user gets the role.

Tom has AD Group 1 and 2, but not 3: The 3rd condition is True because they do not have Group 3 and the user gets the role.

Mary has AD Group 1, 2, and 3: None of the condition are met and the user does not get the role.

Search

You can try to preview this criteria in the Search with a query like this:

(@access(name:"Some AD Group 1") OR @access(name:"Some AD Group 2") OR @access(name:"Some AD Group 3")) AND (attributes.cloudLifecycleState:active OR attributes.cloudLifecycleState:prehire)
6

Entitlement is a multi-valued attribute and a “Not Equal To” will be true if the user has even one AD group in addition to these 3. In IIQ, we overcome this problem by using COLLECTION_CONDITION Filter, but I am not aware of a similar feature in IDN. You may need to open a SailPoint case for this.

Try this query , but I am not sure it will solve your problem:

NOT(@access(name:"Some AD Group 1") OR @access(name:"Some AD Group 2") OR @access(name:"Some AD Group 3")) AND (attributes.cloudLifecycleState:active OR attributes.cloudLifecycleState:prehire)

One more thing you can try is to use a Transform to do this calculation and set a true/false flag on an Identity Attribute and use that in the Role Assignment Criteria.

7

Thanks Prashanth and Edward. We need a configuration with this logic:

If user does not have one or more of AD Groups 1,2 & 3, and their lifecycle state equals either Active or Prehire, then provision role.
Else, don’t provision role.

I apologize if I am being obtuse, but given your statements above, it sounds like the UI does not support this type of configuration. Is that correct?

Thanks