| Subcribe via RSS

SailPoint IIQ: BuildMap – I Told You So :-)

Okay, here’s an article I wasn’t planning on posting, but based on some feedback I received privately via email, I thought I would throw this one example out there. Sometimes the simplest and unlikeliest of examples can tell you a whole lot about the plumbing of a product such as Sailpoint IIQ. Concerning my most recent post on SailPoint IIQ Build Map rules, this next exercise I think will fit the bill of being quite revealing even though simple and extremely unlikely to mirror real world.

I Told You So :-)

In my last post, I indicated that Build Map rules (as well as other rule hooks in Sailpoint IIQ) do not care what you are doing inside them, in general. In the case of the Build Map rule, I stated that Sailpoint IIQ does not do a single thing to validate your code. It does not validate it against your application schema; it’s trusting you 100% to wire your build map rule to your schema in the right way — 100%. The only thing Sailpoint IIQ does do is map fields from your build map into a resource object (later in aggregation processing) that matches the schema, which is a short way of saying…

(1) If you don’t provide a field from your return map that matches the application schema, that field in the schema will be blank (or null), and…

(2) If you provide a field from your return map that does NOT match the application schema, that field in the build map will be dropped.

That’s it. The rest is up to you and here’s a very small example that in my mind pretty much demonstrates everything about how build map rules work.

Setting This Up

Let’s set this up. Try this in your development sandbox. First, create a plain text file that has nothing in it but one number per line — lines numbered from say 1 to 25. Nothing else. This is easy to setup on the Linux command line. (For you Windows peeps, I’m sorry to say it may be just as easy to jump into NotePad and bang out 25 lines by hand! :-( :-))

$ perl -e 'for (1..25) { print "$_\n" }' > dummy25.txt

More »

Tags: , , , , , , ,

SailPoint IIQ: Keep Application From Aggregating

September 12th, 2012 | No Comments | 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. :-)

Tags: , , ,