No Compliance Rule Has Been Violated LieP

When you say one condition is

joshua fellers said:

Property Business Role is X,Y,Z

are you referring here to the person condition? In that case, the test is against Person.UID_Org and the question remain what you are requesting to assign the business role to the person?

Here is a screen shot of the rule.

Means, as I have suspected. What about the other part of my question? This is the one that is of more interest.

Not 100% sure what you are asking. For example, a request for the "ISSM" role to be assigned to a person who already has a system admin account def should be denied (passed to exception approvers) but the workflow is simply passing it as no rule violated.

Request is a ITShopOrg request-able.

Your condition for the persons limits the check to persons where Person.UID_Org is one of the UIDs for Cyber ...

The role membership you are requesting is for a secondary membership in PersonInOrg I assume from your answers. Means, at the point in time of your request the rule will not be violated.

Do you have a custom process in place that changes the primary business role assignment somehow? That would explain why the check is able to find a violation later on.

I was not aware there is primary/secondary memberships of roles? We do not have anything that sets any role as being primary. Are you referring to XOrigin? There are dynamic roles that the person will inherit when being granted one of these roles such as ISSM. Are you suggesting it is the dynamic roles that are violating the policy? In that case, how do I write the rule to prevent the assignment as intended? Reading the role as written, do you get the intention? How can I fix it?

Yes, there are primary and secondary memberships in role possible in One Identity Manager, but after some digging, I do not think that this is the issue here.

Reason for the seen behavior is, as assumed earlier, the way you have defined the rule leads to the seen behavior. You have limited the persons, that should be checked against an assigned account definition with the condition for your business roles. So when the risk analysis during the approval workflow is checking the rules that might have been violated,  it will jump over your rule, because the recipient is currently not an affected person according to the condition of your rule.

When the request has been fulfilled, the user is matched by your person condition and the compliance check will find the violation.

To avoid that, and to be able to detect a potential violation due to the request you have to options.

Option a) Define two compliance rules to check your use-case. Rule one has the business role assignments in the upper person condition and checks against the account definitions in the lower part. And the other one checks against the account definitions in the upper part and against the business role memberships in the lower part. In that case, one of the rules will be violated during the request depending on what type of assignment exists prior to the request. A drawback is that after the fulfillment you end up with two violations, one for each rule.

Option b) Re-define your compliance rule and remove the condition in the upper part and replace it with a check against the business roles in the lower part with the type "at least one role or organizational assignment". It should look similar to the screenshot I've attached. Please check the behavior of the proposed rule to see if it fits your needs and performance expectations.

Thanks Markus, Option B works great.