| Subcribe via RSS

SailPoint IIQ: Keep Application From Aggregating

September 12th, 2012 Posted in IAM Development

One of the primary vendor products for which we at Qubera provide expert advisory and implementation services is Sailpoint IIQ. It’s really a terrific product in a lot of ways and it’s capable of some pretty incredible things in the GRC arena.

I won’t go into the whole sales pitch here. The main thing to note from a technical perspective is, Sailpoint IIQ is fairly easy to use out of the box. However, some of its sophistication necessarily brings some complexity, and under the covers, Sailpoint IIQ offers a plethora of customization options for the not-so-faint-of-heart.

I’ve been wanting to throw a few simple technical and business use cases around that can either serve as a taste for Sailpoint IIQ and it’s capabilities or, alternately, give you a starting point for some use cases you may need to solve on your own. As always, Qubera is there to help if you need expert implementation services — just give us a call. :-)

Let’s start with something really super simple, but for which some of you out there may have wanted to do and never thought of doing. Sometimes, it’s the simplest stuff that provides the most elegant solution. At the very least, it’s always interesting to me to see how others have solved problems.

Technical Use Case: Prevent Application from Accidental Aggregation

So you are in your Sailpoint IIQ sandbox or development environment. You’ve created an application using one connector type and then recreated that same application using another connector type. Say the first connector type was DelimitedFile (CSV), and you’ve now migrated that application to a JDBC connector. You don’t want to delete the DelimitedFile (CSV) connector application because there is perhaps BeanShell code you’ve developed or you’ve perfected a merge or entitlements situation to work just right (*).

Whatever the reason, you don’t want to delete the original connector, but yet… you want to make sure it is never accidentally aggregated either via a task or from the IIQ console. Remember, this is your development environment or sandbox… You would never do something like this in Production, would you?! (Then again, maybe you would?! :-))

In most cases, you could:

(1) Create a Build Map rule for the old connector — call it “BuildMap – Do Not Aggregate”.
(2) Simply return an empty HashMap.
(3) The connector will not aggregate and there will be no errors in most cases.

This will work for most applications, unless you had a Build Map rule that was creating either the application’s Identity Attribute or the Display Attribute.

// BuildMap - Do Not Aggregate
// Don't allow the application to aggregate -- just return an empty HashMap.
return new HashMap();

Salut from Montreal!


* – Yes, you could export the application to XML for safekeeping, and yes, any associated BeanShell code will still be accessible from the Debug pages even if the application definition is deleted. :-)

Comments are closed.