Is there a reason this no longer exists?
There was so much use for the Before/After pair (e.g., remove an attribute in Before, do something with it in After) in IIQ.
Wow! I’m new to IDN hence, I didnt know that there arent any before/after rules. I would really want to know why as well given how extensively we have used that in IIQ
I was having same question @drosenbauer
When I started working in IDN, I was comparing a lot with IIQ and was expecting to have same features in IDN as well. But as time passes, I started adopting to IDN world.
Coming to your question,
We use After provisioning Rule mostly for,
Sending email confirmations - We can use workflows for that in IDN
Audit Events - Not sure if we have custom Auditing in IDN yet
As IDN is low-code SaaS platform, we should be able to meet our requirements with in-built solutions without much customizations.
IDN is evolving at a faster rate, may be if we (Developers) provide some insights why we need After Provisioning Rule, even Customization Rule or some other Rules, IDN product team might consider in future, we can submit an idea and we need voting for that to be considered.
P.S: This is my view, I am just expressing. We need someone from SailPoint team to confirm on this.
But I am happy to see that, we can be part of SailPoint products core development directly or indirectly.
Thanks
Krish
1 Like
In my case, I’ve heavily used both Before and After Provisioning rules to work around issues with the connectors in a customer’s installation. For example, the AD “move” functionality is pretty awful, in both IIQ and IDN, but it’s trivial to fix with an After Prov rule. Salesforce has some order-of-operation problems, but you can fix this by rearranging the Provisioning Plan in Before Prov and then catching and ignoring errors in After Prov.
I’d argue that both Customization and After Prov rules ought to be connector rules in an IDN context, rather than cloud rules. In fact, I think we need a connector-rule version of Before Provisioning, too. It’s useful to be able to query the end system (e.g., “does the account already exist in Salesforce?”) in Before Prov.
As an example of a Customization rule: Workday. We’ve worked with customers with heavily customized Workday systems, where we needed to pull additional employee information via RAAS as part of a Customization rule. We’ve also done field validation in Customization for higher ed customers, allowing them to have a custom UI that just read a searchable “invalid” field from the Link. Some of our Customization rules are 800 lines of code or more.
I agree with you @drosenbauer
We definitely need customization Rule and After provisioning Rule and should be connector level as well. As most of the data we will have in Resource Object while aggregating and in Provisioning Plan in After Provisioning Rule.
Here’s the process I’d find ideal. It combines the best of both worlds - the cloud rules can do things with the IDNRuleUtil and other things that require “live” data access, and the connector rules can do whatever with the plan or the connector and don’t need to cost Sailpoint hosting resources.
ProvisioningPlan or AccountRequest arguments, which are just a Map, could be used to pass data from the Cloud BP to the VA BP or downstream.
It looks like it was an intentional decision to not support after operation cloud rules. IDN is trying to move away from the need for rules, but it looks like the need for this specific rule type remains. Can you submit an idea and share the link here? If anyone wants to see the after operation rule on IDN, they can vote for it and share their use case in the idea.
I can add it as an idea shortly.
To be honest, the only way IDN is going to get rid of rules (particularly this trio of rules - customization / before / after prov) is to have the connectors work for every use case out of the box. That’s a VERY lofty goal, particularly if connector updates only happen every few months.
That’s why Web Services connectors still have the before/after operation rules, and that’s why everything else ought to have them too.
https://ideas.sailpoint.com/ideas/GOV-I-2990
Please go vote on this idea if you’d like to see this feature.
1 Like
IDN does have the provisioning completed event trigger that you could use in lieu of an after rule. You can use it in workflows or in a standalone application. I don’t know if it covers all of your use cases, but it might alleviate your immediate needs for now.
Yeah that does cover some (but not all) of the use cases. It’s the ability to wrap connector operations with workarounds that’s the real advantage, not necessarily just “doing stuff after stuff”. IDN can certainly do stuff after stuff.
One of our current customers has a problem where an AD account is moved, and then IDN tries to create a new account with a new username (via role) while the delete/add is still being processed by aggregation. It’s basically a race condition with a very long time window.
In IIQ, I would:
- Use a Before Provisioning rule to detect the situation by querying AD directly. Correct the DN to the “real” one (which is still inbound via aggregation) before it gets to the connector.
- Provisioning will FAIL, because the account does already exist. IDN just doesn’t know about it yet.
- Use an After Provisioning rule to catch that “FAIL” response and alter the ProvisioningResult so that it’s a success - before the result reaches the provisioning engine.
Neither part of this workaround is possible in IDN. The BP part isn’t possible because BP runs in the cloud and can’t query the connector. The AP part isn’t possible because After Prov doesn’t exist.
There are some IDN-ish things you could do, and we have thought of those.
For example, you could catch the Source Account Delete event and set a flag on the Identity (via self API calls) until a Source Account Create happens. The role could then be altered to exclude those accounts. That shortens the race condition window to the time it takes to respond to the event. Not great if you have 4800 roles, though.
It’s just such a wild level of customization and undocumented data flow for something that could be handled in like 12 lines of Beanshell.
1 Like
You could also resolve this if a custom SaaS Connector could wrap an OOTB VA connector. (Can they?)
I just submitted two separate Ideas that could help with this in IDN:
- Allow HTTP requests to originate from a specified VA cluster
- Workflow Action: execute Powershell script on IQService host
Either of these could be used to run scripts on an internal host based on triggers like “Source Account Created”, “Source Account Updated”, “Identity Created”, “Identity Attributes Changed”, etc.
This is a very good idea, SailPoint would love to do that as they have plan to remove dependency on Rules. However as a developer, I would like to do some development instead of using drag and drop solutions.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.