we have a requirement to implement SoD policies in Identity Now or ISC as part of campaign reviews. But I’m not sure how this is feasible in a reasonable manner to a business user who has to review the violation.
We created the policy, we can see the violation in the report.
We create a campaign - but I have to select which two accesses e.g. entitlements or access policy that are the subject of the violation - which means there was no point in creating policy in first place
When I create campaign for the end-user it just looks like a normal campaign, they have no idea this is related to an SoD violation (yes I could name it something like “SoD Violation campaign” ) but it doesn’t show any reference to the policy so I don’t have any info related to policy.
There is no way to kick off a mitigation workflow if the SoD is temporarily OK.
Hi Faisal @fas702-fs Getting every single bit of SoD functionality from IIQ in ISC is just not possible, mostly due to how the platforms are designed and how they get implemented. But we CAN focus on helping you find a way to achieve the business requirements a bit differently, if you are open to that. I believe you can automate policy violation remediation in an ISC workflow, using APIs. Is that what you need to achieve?
In ISC, both Campaigns and policies are search query driven, as you found.
Before I go too deep into pitching my solution idea, could you perhaps clarify a couple of things:
a.) Regarding your #3: “There is no way to kick off a mitigation workflow if the SoD is temporarily OK.”
--does “OK” mean that there are no violations against the current policy? If the violation report is empty with no violations, I can’t see why remediation, mitigation, or a workflow would be necessary in that case. Perhaps I misunderstood what this statement implies.
b.) What exactly is the business requirement?: “we have a requirement to implement SoD policies in Identity Now or ISC as part of campaign reviews.”
--What does an integration between SoD policies and campaign reviews look like for your organization? For example, which comes first - the violation report or the campaign? Is the campaign used to remediate policy violations, OR does the policy get created as the result of a campaign review?
Thanks for you response @amy_shillinglaw - I am very open to looking at alternate ways to meet our needs in ISC. Using the APIs, workflows, etc. is perfectly fine.
I will try to clarify the use-cases as per your questions.
Probably first to explain, we believe that managing SoD violations requires more than a report query that is sent out to people or a central team to manage directly in SP. We want a self-service approach so that our business users can manage themselves.
This is the ideal scenario:
1. We define an SoD policy that defines Entitlement A and Entitlement X are not permitted.
2. On a daily basis an automatic check is done to see if any new users have A and X
3. Where a new violation is detected, a new SoD campaign is created and assigned to the policy owner or person delegated to manage it - the “violation reviewer”
4. The “violation reviewer” sees this campaign in their inbox.
5. When they review in the UI they see - Entitlements A and X, the SoD Policy name, a link to the SoD policy details (description, etc.)
6. They have the option to “remove” A and X, but also a “mitigate” button
7. Mitigate allows the SoD violation to be “approved” due to some valid reason e.g. User has accounts payable and accounts receivable, but this is permitted as the Finance department is too small as someone is off work due to illness. In this case pressing mitigate you have to provide a valid reason for mitigation.
I hope that help clarifies. If not, happy to add more context.
"…we believe that managing SoD violations requires more than a report query that is sent out to people or a central team to manage directly in SP…"
I am 100% right there with you! And, I have been chatting with internal SailPoint teams about the future of SoD and there is a priority focus on this functionality evolving to better fit needs! Although we don’t have it today, please be patient!
I appreciate the context also. Very helpful. And it matches what I was thinking: policy violation leads to a campaign.
For this scenario to be accomplished with a workflow, first, define your SoD policy, as always. For the workflow itself, here is what I was thinking, some of the components it would have include:
Then you need to parse the report to see if violations are present.
Workflows have a Loop operator - you may need to leverage that to loop through the results and identities
Use the Define Variable operator: use this to capture and store some of the characteristics about the policy violations and identities: ids,
Create Certification Campaign: You can populate the campaign details (name, reviewer, etc.) dynamically with the name of the policy, identity, OR a combination of hardcoded and dynamically attained values. Use the variable selector/JSONPath.
Wait (X) minutes to ensure the campaign gets generated
Activate Certification Campaign…
In ISC campaigns, a violation owner/reviewer simply gives the thumbs up to allow that person to keep the access. It should do the same overall as your proposed “mitigate” button, in theory, correct?
The workflow and our APIs can’t directly tap into the Certifications UI page to satisfy #5, 6…BUT!
If you OR anyone on your team is attending Navigate this year, there is a new UI Development Kit being released and a Hackathon, to innovate and develop new custom solutions. Does that sound interesting? You do not have to attend Navigate to participate. You can join a team - at least one person from the team must attend the event though. Details here:
I realize this doesn’t satisfy literally every step in your business needs, but it should get you to MOST of it.
