| Subcribe via RSS

SailPoint IIQ: Creating & Using Rule Libraries

September 19th, 2012 | No Comments | Posted in IAM Development

So you’ve been writing and using simple BeanShell rules in Sailpoint IIQ but you’ve come to a point in your solving of use cases where you’ve got code replication in various places. This, as in other development situations outside of Sailpoint IIQ, is a perfect scenario for consolidating such code into a library of some sort (you are thinking, right?!) and calling that code from the rules you are writing.

Code consolidation is just good, universally accepted development practice. But can this be done in Sailpoint IIQ, and if so, how? Glad you asked. Here’s how you do it. We’ll use an over-simplified example in a very easy use case to illustrate.

Creating A Rule Library

The easiest way to create a rule library from scratch is to go into the Sailpoint IIQ debug pages and grab a rule you already have. Grab the rule XML from the text area and cut and paste it into your favorite editor. Then pare your XML down to this:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="My Library">

// My Library - only a comment for now... :-)


Ha, well I guess… there you go. You can now just use the above as a rule library template instead of digging this out of your Sailpoint IIQ debug pages. :-)

Save this to an XML file on your local hard drive. Make sure you change the name of the library on the 3rd line above to something that makes sense for you. Then import this XML into Sailpoint IIQ. You can import this XML in one of two ways:

(1) Navigate to the System Setup page and choose the “Import From File” option, or…
(2) Import from the IIQ console using the import command.

Now, re-navigate to your debug pages, re-list your rules and you should see a rule named “My Library” (or whatever else you might have named your rule). For updating this rule and actually adding code, you’ll need to edit this rule from right here in the debug pages as it’s not going to show up anywhere else, really. We’ll keep that in mind for later.

The Background/Sample Use Case

Okay, so now you’ve created a rule library — simply a place to stick code that will be shared by other rules. How to we reference this library?

Before we get into that, let’s look at our use case code. We have two build map rules for aggregation — one build map rule called from a CSV connector and the other build map rule from a JDBC connector. In both cases, we’re going to say each needs to build a string formatted a certain way, and we want to isolate this formatting to one place — in our new rule library — and call that code from both rules.

Here is the CSV build map rule:

// Imports.
import sailpoint.object.Schema;
import sailpoint.connector.Connector;
import sailpoint.connector.DelimitedFileConnector;

// Build an initial map from the current record.
HashMap map = DelimitedFileConnector.defaultBuildMap( cols, record );

// Only perform these steps for account aggregations.
if (schema.getObjectType().compareTo( Connector.TYPE_ACCOUNT ) == 0) {
   String path = map.get( "path" );
   String filename = map.get( "filename" );
   String filespec = path + "/" + filename;
   map.put( "filespec", filespec );

// Return the resulting map.  For group aggregations, the default
// map falls through and is returned.  For account maps, we return
// the modified map.
return map;

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: , , ,

My Macbook: Takes a BEATING And Keeps On Ticking

September 7th, 2012 | No Comments | Posted in General

Well, I’m overdue for a blog post anyway, and this was something fairly notable.

For a number of years now, both from the standpoint of pure development as well as on the creative side, nothing beats an Apple computer. It’s a developer’s dream box with a rock-solid, commercial frontend UI (eg. Cocoa) and backend, under-the-covers BSD-like OS… MacOS X is simply the cat’s meow. Especially if you are a Java/JEE developer. (If you are a .Net developer, I’ll give you a free “pass” on using Windoze, and even then… running Windows on VMware Fusion is still better than a real Windoze machine!)

So the “truly notable” was today, after two client trips to Boston, a client trip to Montreal, and untold code written and apps running later — every application you can think of under the sun (eg. Word, Excel, emacs, Eclipse Indigo, Evernote, LibreOffice, Oracle SQL Developer, MySQL Workbench, MySQL database, Chrome, Firefox, Calendar, VMware running a 4gb Windows 7 Pro machine, CoRD, VNC, Cisco VPN, Dropbox, eight terminal sessions, Tomcat running SailPoint IIQ, blah, blah, blah — notice any Microsoft “pig apps” in that list??!!) — after 43 days straight… my MacBook Pro gave hints (only hints!) it was maybe time to reboot. :-)

Try that on a Windows machine sometime. :-) Uh-uh… Ain’t happenin’… :-)

Tags: , , ,