| 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">
  <Source>

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

   </Source>
</Rule>

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

Developer Tomcat Settings for Sailpoint IIQ Sandboxing

October 10th, 2011 | No Comments | Posted in IAM Development, IAM Engagement

Working on IAM projects and out on client sites for Qubera Solutions, our technical peeps all have developer sandboxes we use for prototyping, setting up read-only connectors to outlying systems (eg. PeopleSoft, AD, LDAP, JDBC connections, etc.), doing RBAC analysis and just about anything GRC related. We sandbox just about everything we can or run pre-configured VMware VMs on laptops outfitted with as much memory as we can. (My Macbook Pro is spiked out at 8gb RAM.)

Generally we use Tomcat for the app server piece but not always. None of this is earth-shattering news. Any developer or integrator of note at Any Company USA and around the world is going to have at least “A” sandbox running if not multiple. Just whether those sandboxes are configured and tweeked properly is going to be the only question, really.

As it relates to Sailpoint IIQ, first of all, me running a Macbook Pro, it’s technically “not supported.” But the IIQ deployment, like Oracle Waveset, is just a WAR. For the middleware piece (the DB layer aside), you essentially deploy a WAR, import your objects from XML, and you are off and running. Nevertheless, the “non-supported” aspect of a MacBook tended to rear its ugly head and I had frequent hangups in Tomcat until I tweeked a few things. It turns out setting my JAVA_OPTS to the following not only helps, but seems to be recommended from a trusted source. (I don’t have permission to credit here, much as I would like, so just take it for what it’s worth.)

I’ll “split this up” in a syntactically correct way so this doesn’t extend the page on the blog entry, but you can put these settings all on one line; hopefully that is obvious:

JAVA_OPTS="-server -Xms3072m -Xmx3072m -XX:NewSize=1024m -XX:MaxNewSize=1024m"
JAVA_OPTS="$JAVA_OPTS -XX:MaxPermSize=1024m -XX:CodeCacheMinimumFreeSpace=2M"
JAVA_OPTS="$JAVA_OPTS -XX:ReservedCodeCacheSize=64M"
JAVA_OPTS="$JAVA_OPTS -Dsun.lang.ClassLoader.allowArraySyntax=true"

More »

Tags: , , , , , , , , , , , , , , , ,