This month, we’ll be hearing from @philip-ellis as he teaches us about Connector Customizers for SaaS Connectivity. You can learn more about Connector Customizers from our latest announcement here:
New to SaaS Connectivity all together? Checkout our last stream from Phil on getting started with SaaS Connectivity:
Just a quick update that our November session has changed from the SailPoint CLI to our new Connector Customizers for SaaS Connectivity. You can read the full announcement here:
I was going to ask in the live stream but I’ll go ahead here. Perhaps my use case is different because it’s on a VA connector but I figured I’d ask anyway.
One of the examples you put together was overriding the displayName account attribute population and creating your own. Couldn’t you also do that inside a static transform on the create provisioning policy? Just trying to see if that’s one of those “more than one way to do it” type use cases
If that particular use case can be done in both places, it would be helpful for us that are new to this space to understand a use case that can only be (reasonably) accomplished using a customizer.
I get that a 45 minute live stream can’t be an all-encompassing demonstration of a particular feature, but it would help us to understand the “why” of using this feature.
Thanks for the great live stream, this is really exciting to see and I am excited to find some practical use cases!
To elaborate on my question about correlation config. I am currently trying to solve an issue with the LastPass SaaS connector. LastPass doesn’t seem to have a field we can use for something like employee number, so we only have username to use for correlation which is email. Emails are not completely unique in our org because our identities for Service Accounts use the owner’s email, and the owner’s own identity cube also has the same email address. This is causing a good portion of our LastPass accounts to remain uncorrelated.
I have tried to pull in additional attributes to use to write something like employee number so we could use that for correlation, but I haven’t been able to find one to pull in. Currently, my only thought to resolve this is to create a new identity attribute, lastPassEmail, only apply that attribute to the identity profiles I want to be in scope for correlation, have it set to be the same value as email, and use this attribute for correlation (lastPassEmail=username). I haven’t implemented this yet, but this should allow for our accounts to correlate properly, I just normally try to avoid creating identity attributes for a single source/use.
I was wondering if we could somehow use customizers to have a complex correlation logic along the lines of only trying to correlate accounts to specific identity profiles, or exclude identities from certain identity profiles from correlation. Just trying to think of another solution for this issue. IT was convenient timing for this live stream and the fact that these customizations are designed to be used on OOTB SaaS connectors.
Currently, my only thought to resolve this is to create a new identity attribute, lastPassEmail, only apply that attribute to the identity profiles I want to be in scope for correlation, have it set to be the same value as email, and use this attribute for correlation (lastPassEmail=username).
I had to do this in order to correlate people’s elevated Azure user accounts to their identity because the on-prem AD attribute we used for correlation didn’t exist in Azure.
Granted I’m not helping answer your specific question, but just wanted to confirm you’re not the only one who’s thought of using this method
I appreciate that Mark, always nice to hear someone else has experienced a similar issue! Not that it is good someone had a problem, just good to know you aren’t the only one.
So yeah this solution seems like it will work for us, but it isn’t really scalable, so I was just looking to see if there was another option in case we encounter this again for other sources.
A transform could certainly be used to do the same thing. In general we would recommend customers to use a transform for those simple types of operations.
With Connector Customizers, since they are so easy to build and test, I could see a lot of customers opting to use them instead of transforms for even these simple operations, and there isn’t anything inherently wrong to using them in that way.
The advantage to using a transform is that it can be used on all connector types (VA as well as SaaS Connectors), and you can also apply multiple Transforms to a single connector, while only one customizer can be applied to a connector at a time.
One way you could resolve this correlation issue would be to make an API call into IDN in the customizer code in the beforeAccountCreate operation to fetch all accounts that are tied to that email. I’m guessing you would be able to decipher which accounts are system accounts and which are a user account based on other attributes on the user in IDN. If so, then you could assign the actual IDN user ID to the attributes and send it along for a perfect correlation.