| Subcribe via RSS

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… :-))


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:


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

Tomcat: Open Document Directory Listings

December 6th, 2012 | No Comments | Posted in General Idm/IAM, IdM Infrastructure

A lot of us IdMers deploy and run our favorite flavors of IdM tools to and on Apache Tomcat in our personal sandboxes. It’s just an easy servlet container to deploy to. Sun Identity Manager/Oracle Waveset and Sailpoint IIQ come to mind. While this article isn’t necessarily written to plug Sailpoint IIQ, my desire to allow the PDF documents that ship with IdentityIQ to display in my sandbox Tomcat installation did lead to this article being written.

Configuring Tomcat To Allow Directory Listings

Tomcat used to set directory listings to true out of the box. It seems somewhere along the line, this default behavior reverted to false. I’m not sure when. As with plain vanilla Apache HTTP Server, Tomcat does provide directory listings of URLs which don’t point to servlets and other configured objects. It does this through a default servlet (so a servlet is still running — as you might imagine.)

This default servlet can be configured to display directory listings. To do so:

(1) Navigate to the root of your Tomcat installation.

(2) Edit the ./conf/web.xml XML config file.

(3) Look for this section of code and make sure the listings parameter is set to true


(4) Restart Tomcat

(NOTE: Be aware this changes the directory listing behavior for ALL APPLICATIONS deployed to Tomcat. If you want directory listings turned off in other applications, you need to make a choice of which web.xml‘s to edit to gain the desired result!)

XSLT Transformations

For those looking to take things into the bonus round, just so you know, the Tomcat default servlet runs these directory listings through an XSLT transformation. If you are especially ambitious, you can override these XSLT transformations with transformations of your own. “Skin” your own directory listings, essentially. If your company for instance insists on proper branding no matter what is served, or, if you were serving this listing up in an iframe on another server, this would be the way to transform the look and feel of the Tomcat directory listing to your liking.

I’m not going to do that here.

SailPoint IIQ PDF Documentation

Now we can navigate to where the Sailpoint IIQ PDF documentation is kept and view these docs right in our browser:

SailPoint IIQ PDF Documents Directory Listing

A really nice benefit is that each time you patch Sailpoint IIQ, this exact directory will be updated with the latest and any changed docs from Sailpoint. As you can see above, I’ve already patched my Sailpoint IIQ v6.0 installation to v6.0p1, and as a result, I have the corresponding v6.0p1 docs as well as the original v6.0 docs.

For IdentityIQ, Delete In Production

While we’re here, just another security pointer… I recommend deleting the PDFs in your production install of IdentityIQ, no matter which application server you choose to install to. It only makes sense. While the docs may not be served via HTTP, there are other people who have access to the file system (system and network admins, etc.) and you want to keep your security documentation inhouse.

@IdMConsultant for IdM Related Tweets

December 2nd, 2012 | No Comments | Posted in General Idm/IAM, IAM Development, IT Industry, Security

I’ve been wanting for a while to create a dedicated channel on Twitter for tweeting content specific to Identity & Access Management. As of now, I’ll be doing exactly that via a new @IdMConsultant Twitter account. (Totally shocked that that Twitter account was actually available!)

So look for short, I-hope-to-be-handy tweets on the various IdM products we implement, support and provide expert advisory services on through Qubera Solutions. Expect tweets such as Implementing Full Text Search for #SailPoint #IIQ6? Don’t forget to copy the resulting index files across your server farm! Qubera Solutions is IdM/IAM vendor agnostic — we advise and implement solutions that fit your specific needs and requirements, so expect tweets that are vendor agnostic as well, but narrowed to just IdM/IAM.

(Traffic on my older and still existing @TechnologEase Twitter account will carry more general content relating to technology in general and what TechnologEase exists for which is Internet Consulting. Done Right.)

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