| Subcribe via RSS

Stupid SailPoint Developer Tricks

Hello, mates — as they say Down Under, where I happen to be at the moment on a rather large Sailpoint engagement. It’s been a while, and I’m sorry for that. I keep promising more, new and better content and haven’t delivered.

The last couple of months however have been absolutely crazy and there have been some changes on my end, as you perhaps can see. Now that things have shaped up a bit, maybe I can get back to the business at hand here on the blog, again as I have time.

Stupid Pet Tricks

When I was growing up and in college, a famous comedian became famous (partially) by having a segment on his show called “Stupid Pet Tricks.” Some were hilarious and some… belonged on the 1980’s “Gong Show.” (If you’ve never heard of “The Gong Show,” trust me, you aren’t missing anything).

Since that time, I’ve always thought of various developer tricks in the same light. Some are quite slick and useful and some… really just need to be buried. I’ll leave it to you to decide on this one.

Out of sheer laziness, while onboarding Sailpoint applications that feature a BuildMap rule (eg. BuildMap, JDBCBuildMap, and SAPBuildMap), I sometimes utilize a method for “printing debug statements” that I can see directly and immediately in connectorDebug, without having to jump into or tail the Sailpoint IIQ log or application server logs.

It’s also just a bit less verbose as the Sailpoint IIQ logs typically have a large class identification prefix in front of them, which can get rather cumbersome and make it more difficult to pick out one’s intended debug output.

Plus I hate changing logging levels in log4j.properties even though the Sailpoint IIQ debug page allows me to load a new logging configuration dynamically. In short, I’m just a lazy, complaining type when it comes to Sailpoint IIQ debug statements.

Someone mentioned this would be worth blogging about, so here goes. (At the very least, this is an easy article to write and perhaps will get me back into the blogging swing?!)

__DEBUG__ Schema

Now, I would definitely recommend doing this only on a local or designated sandbox and then making sure you clean up before checking in your code. (You are using some form of source code control for your Sailpoint IIQ development, aren’t you?!)
More »

Tags: , , , , ,

SailPoint IIQ: Move Over, Rover

I’m getting ready to do some customer training on Sailpoint IIQ v6.0. Getting ready for the trip has been a good impetus to get my rear end in gear and get up to date. I’ve been running Sailpoint IIQ v5.5 “bare metal” on my MacBook Pro pretty much since Sailpoint IIQ v5.5 was released. I have procrastinated getting Sailpoint IIQ v6.0 installed on my laptop. (Mainly because I have Sailpoint IIQ v6.0p5 running in the mad scientist lab on ESXi accessible via VPN.)

Side By Side Approach

So, it was time to install Sailpoint IIQ v6.0, but… I don’t and didn’t want to obliterate my Sailpoint IIQ v5.5p6 installation; I have too many customizations, test applications and rules I don’t want to loose and still want to be able to run live. I’ve been running Sailpoint IIQ with a context root of /identityiq and with a MySQL database user of identityiq.

When I run multiple versions of Sailpoint IIQ side by side on the same machine, I’ve adopted the practice of running each installation as /iiqXY where XY is the version number. So I wanted to run /iiq55 and /iiq60 side by side from the same application server. (I could also take the approach of running multiple instances of application server and run one installation from one port, say 8080, and another from another port, say 8081.)

So how to “lift and load” the existing installation at /identityiq to /iiq55 without reinstalling everything and re-aggregating all my sources? Here’s what I did.

DISCLAIMER: I’m neither advocating nor de-advocating this. Do this at your own risk, especially if your environment differs from mine. I make no claims or warranty of any kind. This worked for me. If it helps you… great.

The Environment

Here was my environment:

Operating System Mac OS X, Mountain Lion, v10.8.3
Application Server Apache Tomcat v6.0.35
JRE Java SE JRE (build 1.6.0_43-b01-447-11M4203) (64-bit)
SailPoint IIQ SailPoint IIQ v5.5p6
IIQ Database MySQL 5.5.15

Shut Everything Down

First, I shut everything down. This basically meant just spinning down the entire Tomcat application server. The command you might use and the location of your application server scripts may differ:

$ cd /Library/Apache/Tomcat6/bin
$ ./shutdown.sh

More »

Tags: , , , ,

SailPoint IIQ: Aggregating XML

From an answer to a client this morning on aggregating XML in Sailpoint IIQ. I hope this helps others out there:

Regarding your question this morning on aggregating XML… I have seen XML aggregated through the OOTB RuleBasedFileParser connector. That connector requires that a rule be written to run the parser and through that, you could parse and aggregate XML. I mentioned this to one of our Solution Architects after our meeting and he was aware of the RuleBasedFileParser type, but personally felt it was enough work such that you may as well write a custom connector using libraries Java has available to handle XML.

I think between him and me, I would say the following:

(1) From an overall perspective, it’s technically possible using the RuleBasedFileParser connector to aggregate XML.

(2) There may need to be a discussion about the XML in consideration itself to determine the level of complexity of XML coming in, in which case:
(a)…The RuleBasedFileParser may be an adequate choice.
(b)…A custom connector for the XML may be in order.

One other approach could be:

(i) Use a DelimitedFile connector.
(ii) Write a pre-iterate rule leveraging the Java XML classes available to (a) read the XML and (b) create a CSV from the XML for the DelimitedFile connector to consume.
(iii) Use the post-iterate rule to clean up.

As you can see, there is more than one way to skin the XML cat here. This is the case as with most things in Sailpoint IIQ, as I demonstrate in at least one blog post, can be “tricked” in various places into doing what it is you ultimately want it to do.

As with any of this, it’s very common to have to sit down on an engagement and triage between a number of approach options to decide on the best implementation approach. I hope this information helps you with that process.

From the Twin Cities, where we shrug off the second day of Spring with a second helping of Winter, Amigos…

Tags: , , , , , ,

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

SailPoint IIQ: Best Practice – Native Change Detection

December 13th, 2012 | No Comments | Posted in IAM Development, Vendor Specific

This should be a short post. What I want to offer is longer than what I can fit into a tweet (@IdMConsultant), but pretty simple to state. (But since I’m blogging, I will expand slightly… :-))

Background

For the new Native Change Detection feature in Sailpoint IIQ v6.0, Sailpoint warns, NCD needs to be turned on after your first aggregation. Obviously, if NCD is turned on before this, all your “changes” on your first aggregation are going to kick off a lot of needless workflows (at best) and could result in some possibly serious consequences in terms of changes made downstream (at worst, depending on how you’ve customized the resulting LCE workflow, especially if you’ve elected a heavy-handed approach to NCD).

Native Change Detection Best Practice

I would further this recommendation and state, as a Best Practice, don’t turn on NCD until after the aggregations for an application have “matured.” That is, you’ve worked through all the kinks that typically come in a production aggregation scenario. Almost always, there is something “forgotten” in an initial aggregation or even the first two or three aggregations. A transformation rule has to be written… You forgot an attribute… Your app owner and you decide another attribute needs to be added to the application… You forget to mark an entitlement… You don’t realize immediately you aren’t getting all expected data… etc.

(You can “mature” or solidify your application aggregations in one of two ways or a combination of both:

(1) Work out your aggregation details in lower environments. Attributes and schemas here should match what you plan to place into production. But since your data isn’t always the same in your lower environments as in production, you should also…

(2) Allow for a number of aggregations in Production with production data. I would recommend at least 2-3 validated aggregations with Production data to solidify expectations.)

Native Change Detection is a powerful new feature of Sailpoint IIQ that is quickly positioning Sailpoint IIQ as THE authoritative governance application in the enterprise (NCD as well as other new features of Sailpoint IIQ v6.0). So to recap:

Recap

(1) Don’t turn on Native Change Detection until aggregations for an application have matured or been solidified.

(2) Turn on Native Change Detection only one application at a time!! Plan your usage of NCD, and either turn NCD on one application at a time or in small groups of related applications (eg. Active Directory and Exchange). I really recommend one application at a time. If you don’t take this #2 approach, I promise you… you are asking for trouble! :-)

(3) I would even go so far as to recommend enabling one NCD function (eg. create, modify, or delete) at a time. At least in your earliest uses of NCD. So one function per one application at a time.

Plan. Map. Forecast. Test. Execute. Mitigate. Don’t “willy nilly” with this. :-)

Rising above 15″ of snow in the Twin Cities and wishing you the best with this fantastic new feature of Sailpoint IIQ!

Tags: , , , , ,

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: The BuildMap Rule Revisited

Well, I’m behind on posting again. Apologies to those following here who I know were looking forward to this particular post which I promised in person to a number of you.

Build Map Rules in Aggregations

The BuildMap Rule… Just what is a “build map rule” exactly? Maybe you’ve used or even written one, but you admit you still really don’t understand what it’s actually doing or how it really works in the case of account aggregations. I actually get that kind of comment all the time, so don’t feel bad. Let’s crack ‘er open and see if we can crystalize the concept of how this actually works. Once the concept is crystal clear, you’ll know exactly when to use it, and your usage of it will be that much more sophisticated and precise.

Hang On… What Is A Map, First Of All?!

Before we get into what a build map rule is, we first need to cover the concept of a “map” to begin. Again, this is a comment I often get as I am on site implementing Sailpoint IIQ for the first time in enterprises — “what is a map?”

Sailpoint IIQ is built using JEE technology. Therefore, it draws from many paradigms within that reference technology platform. A Map object in Java, or just a “map,” is essentially an indexed name/value pair system. Focusing on strings as the map implementation (it’s possible to have other map types in Java, but we’ll forgo that discussion here), a very stripped down version of a map is something like you might find in a configuration or initializer file of some sort:

name=Chris Olive
address=123 Somewhere St.
city=St. Paul
state=MN
zip=55102

This is also known as a key/value pairing because the name on the left hand side can only occur once. If you are familiar with other programming languages, a Java Map is roughly equivalent to what is called a hash in Perl and Ruby, a dictionary in the older Microsoft development parlances (VBScript, etc.), or a dictionary in Javascript (though popularization of Javascript and it’s object orient model extends this scheme into JSON objects, which again we will forgo delving into in depth in this discussion.)

Here are the equivalent “maps” in some of the languages I’ve mentioned above. If you are familiar with all or any of these, then you know what a Java Map (object) is:

Perl:

my $map = {
   name    => 'Chris Olive',
   address => '123 Somewhere St.',
   city    => 'St. Paul',
   state   => 'MN',
   zip     => '55102'
};

Ruby:

map = {
   :name    => 'Chris Olive', \
   :address => '123 Somewhere St.', \
   :city    => 'St. Paul', \
   :state   => 'MN', \
   :zip     => '55102' \
}

Javascript/JSON:

map = {
   "name"    : "Chris Olive",
   "address" : "123 Somewhere St.",
   "city"    : "St. Paul",
   "state"   : "MN",
   "zip"     : "55102"
};

Java (BeanShell):

// Unfortunately, Java doesn't offer a shortcut way of initializing
// a HashMap. I'll just not comment on that here. :-)
//
// Since Java 5, real Java wants these sorts of things "typed" as
// well.  We'll forgo that and do this BeanShell style as per IIQ.
// BeanShell doesn't require type syntax.

import java.utils.HashMap; // Not required in BeanShell
   :
   :
HashMap map = new HashMap();
map.add( "name", "Chris Olive" );
map.add( "address", "123 Somewhere St." );
map.add( "city", "St. Paul" );
map.add( "state", "MN" );
map.add( "zip", "55102" );

Now, that last example looks somewhat familiar if you’d done any writing (or plagiarizing :-)) of Sailpoint IIQ build map rules already. (Funny how in literary circles, plagiarism is very much frowned upon, whereas in IT, it’s very much encouraged, isn’t it?! :-))

So while we’re here, let me just say that the variable name “map” carries no special significance. People tend to name their variables in simple scenarios according to what they are and the variable name could just has easily been “foo” or “frank” — it’s doesn’t matter (other than when you program that way, things get a little unclear fairly quickly.)

So this would do just as well:

HashMap me = new HashMap();
me.add( "name", "Chris Olive" );
me.add( "address", "123 Somewhere St." );
me.add( "city", "St. Paul" );
me.add( "state", "MN" );
me.add( "zip", "55102" );

IIQ Uses Maps EVERYWHERE

So now that you (hopefully) know what a “map” is, then maybe at least the name has suddenly taken on more significance. “Build Map” means… a Java Map object instance (or just a map) is going to be built. “Why” will be explained in just a moment.

The main thing to emphasize here is… Sailpoint IIQ uses maps literally EVERYWHERE. So just get used to it. And that being said, I can’t think of a concept in Sailpoint IIQ that you need to make sure is rock solid any more than the concept of a map. Again, Sailpoint IIQ uses them literally EVERYWHERE.
More »

Tags: , , , , , ,

Sean O’Neill on OIA versus OIM

March 2nd, 2012 | No Comments | Posted in IAM Engagement, IdM Engagement, Vendor Specific

I was looking into an Oracle Identity Analytics discussion group on LinkedIn the other day and there was a friendly “back and forth” going on between Oracle Identity Analytics features versus Oracle Identity Manager features crossover.  I wanted to highlight the discussion here, specifically with Sean O’Neill‘s response because he really nailed it.

The backdrop, which I will provide here, is something clients ask often for Oracle IdM implementations because there does seem to be some cross functionality between Oracle Waveset and OIM for provisioning, certifications and attestations, as well as some role management, versus OIA for role management, certifications and attestations and overall identity warehousing.

“Oracle Waveset and/or Oracle Identity Manager have similar functionality to Oracle Identity Analytics, so which should I use?”

This is a common question amongst clients as well as implementers.  If you are a client and you see even implementers are divided on when to use which feature in which product, it can get a bit confusing if not unsettling.  The real answer, before I get to Sean’s response, is somewhat three-fold:

  1. (1) The dilemma stems from the fact these were all products derived from different sources and product roadmaps from other companies, and so there simply is crossover in features and functionality.  So the confusion is understandable, even amongst implementers.  In some cases, either answer (“go with OIM“, “no, use OIA for ______”) is “right” and may stem more from an implementer’s comfort level in implementation than anything else.
  2. (2) It’s best, when utilizing these products in conjunction (eg. Oracle Waveset with OIA or OIM with OIA) to settle on the proper division of functionality during the design phase of your IdM project, while keeping mind…
  3. (3) Oracle’s roadmap for both products in the new Oracle Fusion Middleware 11g line.

This will help “settle” the questions during implementation and provide for a more seamless transition to the Oracle Fusion Middleware 11g product line and conformance to that roadmap.

So, when choosing a vendor to implement the Oracle stack, make sure you choose one that understands the Oracle Fusion Middleware 11g product roadmap as well as the specifics of an Oracle technical implementation.  For OIM, you really need technical expertise, as there are many more moving parts for an OIM implementation.  (What a shame that Oracle Waveset was kicked to the curb, but it’s history now, so no sense lamenting it any longer.  A natural product progression for Oracle Waveset users exists in Sailpoint IIQ IMO. :-))  But make sure, when you are RFP’ing for what you know will likely be an Oracle implementation, that you bring on a vendor who thoroughly understands the Oracle roadmap and, preferably, has ties to internal Oracle IdM resources. :-)

Sean’s Response to OIM Functionality versus OIA

Now, for Sean’s clarification on “which to use,” which was the backdrop of the discussion on LinkedIn, I’ll just quote most of Sean’s response:

OIM can do many of the same functions (though not as richly) such as role management, attestations, etc. as OIA, but it can only do it for systems that are connected to OIM. In order for OIM to work with a target resource, it has to be connected to the resource. 

This means using a connector to access the resources user API’s, which introduces cost and effort. This means not all systems in the enterprise will get hooked up.

As most companies do not provision to 100% of their systems, it means they are working with a subset of user entitlement information. OIM is mainly a provisioning platform, using a BPEL based workflow engine to manage accounts across connected systems. (Yes, you can have stubbed, manually maintained resources using emails or flat files to dictate what an admin should change in the user accounts, but that complicates this discussion.)
More »

Tags: , , , , , , , , ,

SailPoint IIQ 5.5p1 Released w/Install Caveat

February 22nd, 2012 | No Comments | Posted in IAM Development, Travel, Vendor Specific

Just a quick note that Sailpoint IIQ v5.5p1 was released this week. Seems to be working great, has a lot of bug fixes and overall is a quick and smooth install. The release notes (if you have a Compass account) go over the details, so I won’t cover them here.

One caveat to mention is this: Do NOT install Sailpoint IIQ 5.5 and then install the p1 release from scratch. Make sure you install Sailpoint IIQ 5.5 sans p1, then do your XML imports (init and init-lcm), login, and THEN go through the p1 patch cycle. Otherwise… surprise! You will not be able to log into spadmin (due to DB schema changes in the patch). Not a great feeling when it happens. Trust me. :-)

Brought to you live, onsite with Sailpoint, from Boise State University. Hoping to see the blue football field before we leave. :-)

Cheers!

Tags: , , , ,

Quick Guide to Rebranding SailPoint IIQ

January 18th, 2012 | No Comments | Posted in IdM Engagement, Vendor Specific

So you’ve got Sailpoint IIQ all installed and humming on your enterprise servers, and your boss walks in and says “My boss says the CIO wants this rebranded for better internal look and feel, to keep confusion down for identity self-service requests. Can you have it done by Monday?!”

Your answer, even if it’s Friday, should be “Yes, sir!!” Here’s how you can do it, covering just the basics. In this exercise, we’ll cover rebranding:

  • The login banner page
  • The IIQ headers on each page, and…
  • The overall CSS colors on each page providing the final L&F

Let’s get started.

Overview

The tools and “skillz” you will need (as they say) will actually lean more on the graphics side than on the Java or HTML development side for this exercise. In fact, other than careful and proper placement of the resulting graphics files inside your deployed application and application server file system, graphical capabilities and understanding of CSS are going to be your primary concerns. If you are not very good at handling a graphical editor like Adobe Photoshop or GIMP, now’s the time to call your friend, Sally, over in Marketing to lend you a hand.

Assuming you know where Sailpoint IIQ is “rooted” on your application server, we’re going to graphically reconstitute a few files. We’ll assume a Tomcat installation here, which should carry over quite nicely for a JBoss AS installation as well. WebSphere, Glassfish, WebLogic and you other app server flavored peeps out there, try to follow along.

For Tomcat, assuming an installed/deployed path of /srv/tomcat6/webapps, you should/would have /srv/tomcat6/webapps/identityiq for your application root. So then, we’re going to graphically reconstitute:

  • $APP_ROOT/images/login.gif
  • All the header*.gif files in $APP_ROOT/images and…
  • identityIIQ-logo.gif

Furthermore, we’re going to, at a bare minimum, twiddle the background-color CSS attribute on five (5) CSS files. We’ll detail all that when we get to the section on CSS.
More »

Tags: , , , , , , , , ,