SailPoint IdentityIQ: Rule and Settings Overrides

One of the primary reasons I write here is to clear up any minor points of confusion with our highly valued Qubera customers, and to enhance their understanding of products we have installed for them just a little better. Especially if I field similar questions across client engagements (eg. “Why does ‘it’ work that way?”), then I make a point to try and blog about those here.

What I want to point out today may not seem like a big deal to many of you, but this topic has come up a number of times with SailPoint IdentityIQ and I wanted to clarify it a bit more for some of you out there. This is a concept that I call “rule and settings overrides.”

Rule And Settings Overrides

You know the feeling you get when you jump into a fully loaded sports car at the dealership… all the buttons and knobs and dials. The “radio” does a million things by itself and then there’s onboard navigation/GPS, On-Star, rear camera, collision detection, choice of manual or automatic in the same transmission… it gets to be a bit overwhelming. “What do all these knobs and buttons DO?!” you think?! I would equate initially running SailPoint IdentityIQ and just about any feature-rich identity management product to be about like that.

It turns out with SailPoint IdentityIQ specifically, there are a number of places where if you turn on or flip or fill-in settings in one place, those settings can actually override options you have set (or thought you had set!) in another place. This can be confusing and may even lead to initial negative impressions of the product.

But with SailPoint IdentityIQ that’s far from being the reality. The designers of SailPoint IdentityIQ actually took a very straightforward approach in determining the “rules” around product features, and it’s really quite logical (and powerful) once you gain command of the product over time. No one blames the maker of an upscale sports car for its complexity, rather they embrace it and learn to leverage all the features over time. After all, that was the reason for selecting a sports car in the first place. 🙂

Rules ARE Overrides

Rules are very easy to help level set in your understanding here. The thing to remember with rules, pretty much across the board with SailPoint IdentityIQ is this: Rules ARE overrides. I talked about this somewhat by going in-depth with BuildMap rules here.

During aggregations, SailPoint IdentityIQ goes through a number of phases. (I discussed those phases somewhat at the link above.) At various points during those phases, the designers of SailPoint IdentityIQ provide you with the opportunity to step in and write your own custom logic to handle your enterprise business and technical use cases. That means that rules ARE overrides.

If you write a rule of any type anywhere in the product, then you are overriding SailPoint IdentityIQ‘s default, OOTB logic for that aspect of the product (eg. aggregations, certifications, identity attribute mappings, emails, etc.). And again, SailPoint IdentityIQ completely takes its hands off during the processing of these customization rules, and provides you with full control at that point. All it does is:

(1) Provide you with objects very likely needed for your customization logic. These are the parameters you see when building SailPoint IdentityIQ rules.

(2) It expects a certain kind or kinds of acceptable return values.

That’s it. Whatever you do in between is up to you. (Needless to say, you can impact performance quite a lot by the type of logic you may choose to employ in any rule, so choose your logic wisely. If you are experiencing performance issues, especially surrounding certain areas of functionality, such as aggregations or certifications, this would be one place to check — check your rules.)

So in short, rules ARE overrides.¹ It only makes sense.

Correlation Rules

One place where a rule can be employed and it overrides specific GUI settings entirely is in correlations. This particular behavior isn’t so apparent, and I thought I would point it out here.

It’s important to understand these instances to cut down on confusion, especially when testing and things aren’t working as you or members of your team would expect. Less importantly, you might formulate a standard approach with which you and your team are comfortable with respect to settings.

SailPoint IdentityIQ provides you with the ability to set up correlations, both aggregation and manager correlations, using a GUI wizard approach. This can be fantastic for getting up and running quickly, most especially if you have very clean data and well-defined, essentially attribute-to-attribute correlations. You’ll be happy to know, however, at least as a consolation, this is very seldom the case with any organization.²

So maybe you start out with the correlation GUI wizard, and then realize you need to customize your correlations, applying better logic, and you write a correlation rule. Again, this could be for aggregations or for manager correlation.

So you have GUI-based correlations setup under the Correlation tab for an application AND you have correlation rules written and selected for Correlation Rule and/or Manager Correlation Rule under the Rules tab. Which are in effect? Well, remember… rules ARE exceptions. So your correlation rules are overriding your GUI wizard settings, even if both are “set.” (Go ahead… try it out.³)

You can leave things that way; it’s not hurting anything. But it could be (and has been for some) a point of confusion. You should decide for yourselves if it helps to eliminate confusion by turning the GUI setting “off,” but if you have rules defined, even if your GUI settings for correlations are selected, the GUI settings will be ignored and the rules you’ve written will come into effect.

Delimited File Columns

Another place where settings can be confusing centers around the delimited file connector. Believe it or not, the delimited file connector is still one of the most popular connectors in any identity management solution, not just in SailPoint IdentityIQ.

In SailPoint IdentityIQ, for the delimited file connector, there are a number of settings as with most of the popular connectors. The two we are looking at here are the (1) “File has column header on first line” checkbox and the (2) “Columns” textbox.

I’ve seen situations where the “File has column header on first line” checkbox has been checked off AND the column names for the input file have been designated⁴ in the “Columns” textbox.

No need. If you have checked off the “File has column header on first line” checkbox, the columns designated in the “Columns” textbox are completely ignored and the headings on the first line of the input file are used instead. This has been another point of confusion on engagements, and I thought I’d point it out here, particularly since the delimited file connector is so popular.

Conclusion

As you gain more and more command over the feature set of SailPoint IdentityIQ, these seeming inconsistencies will make more and more sense to you. You will see that the approach SailPoint IdentityIQ takes is really quite logical. Sometimes products suffer from initial misconceptions due to the plethora of options available, and I think perhaps this is the case with a feature-rich product like SailPoint IdentityIQ. It’s better to evaluate a product based on its strength and ability to easily solve your business and technical use cases, and in that regard, SailPoint IdentityIQ comes shining through.

Coming at you from the Twin Cities where in a brief 1-2 day span this weekend, we’re going to go from a balmy 42 degrees to -10 degrees and 45 mph winds bringing a sub -20 to -30 degree wind chill. Gotta love it. A good weekend to stay inside, practice the Barney theme song, and take your sandbox SailPoint IdentityIQ for a spin, eh?!

Cheers!

Footnotes

1 – As one example, in the posting Keep Application From Aggregating, I demonstrate using a rule to override aggregation completion of an application.

2 – Ancient Chinese Proverb: Data tends toward chaos over time. And not very much time at that. So we really shouldn’t fool ourselves here. “Did he just hint at that data cleanup initiative we keep ignoring?” Yep. I threw this in for free. We’ll talk enterprise data cleanup at some point here. 🙂

3 – Here’s a substitute manager correlation rule that essentially implements, tit for tat, an equivalent attribute-to-attribute mapping one would build and set using the correlation GUI wizards. You can use this and massage it fairly easily into either a correlation or a manager correlation rule and play with it from there:

public Map correlate( String applAttributeName, String identAttributeName ) {
   Map returnMap = new HashMap();
   String attributeValue = link.getAttribute( applAttributeName );
   returnMap.put( "identityAttributeName",  identAttributeName );
   returnMap.put( "identityAttributeValue", attributeValue );
   return returnMap;
}

// If you have "Manager" -> "Employee Id" in the GUI, call correlate()
// below the same way, etc.  Expanding this out to accept multiple
// attribute-to-attribute mappings shouldn't be too hard. :-)

return (HashMap) correlate( "managerId", "employeeId" );

4 – “Designated”… sometimes articulated as “spiked out” (Squire… LOL)