| Subcribe via RSS

SailPoint IIQ: Rule And Settings Overrides

January 18th, 2013 | No Comments | Posted in IAM Development, Vendor Specific

One of the primary reasons I write here is to clear up any minor points of confusion with our highly valued Qubera clients, 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 IIQ 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 on-board 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 IIQ and just about any feature-rich identity management product to be about like that.

It turns out with Sailpoint IIQ 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 IIQ that’s far from being the reality. The designers of Sailpoint IIQ actually took a very straight forward 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 IIQ is this: Rules ARE overrides. I talked about this somewhat by going in depth with BuildMap rules here.

During aggregations, Sailpoint IIQ 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 IIQ 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 IIQ‘s default, OOTB logic for that aspect of the product (eg. aggregations, certifications, identity attribute mappings, emails, etc.). And again, Sailpoint IIQ completely takes its hands off during 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 IIQ 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.1 It only makes sense.
More »

Tags: , , , , , ,