I have been discussing the new features in Validator 1.4. I am working through the list of enhancements in the readme, and trying to explain what each of those items really mean.
* Added Bulk Object Create into LDAP connector
Initially I was jut going to talk about the LDAP connector, but I was curious to see if they had added this to all connectors that talk LDAP (eDir, LDAP, and Active Directory) and they did. But when I did that I noticed that for each of those drivers, they added a divider line, and below it a set of connector specific features.
The three connectors (AD, eDir, LDAP) share basically the same set of Asserts and Sets, but at the bottom have some extra stuff.
First lets talk about Bulk Create Objects, since that is common in all three. First up you specify a container for all the objects to be created in, the usual DN format. There is even a selector to browse for the container you want.
Start Value, is a counter field, as to where you want your objects numbering to start counting up from. Number of objects tells it how long to keep doing it. Delay Time is how long to pause between creates in milliseconds.
As usual you can import fields from an object by browsing, or by specifying a DN to import from.
You can specify the object classes you want the object to be, and finally the attributes with values.
What is kind of neat is that the string CTR will be replaced with current counter number. Thus you could have Given Names and Surnames that have the counter at the end or wherever for better test cases.
Now that they have Bulk Create it is a good thing that the Bulk Delete is available, since you can't have one without the other, without making a mess of your tree.
Now to go see how well creating 1 BEELION objects goes... Then delete them.
Next since Active Directory only has one additional special feature, lets talk about that next, as Convert Binary Value to String and Set Variable.
This takes a variable as the source, and a variable for the output which is a good model, since you could then in principle use it in any context it makes sense, not just in Active Directory. If you really needed the function and did not have an AD system, you could still define such a connector, and then use this test.
The obvious use cases for this in AD are the two examples shown in the Convert To field. Which amusingly has a mouse over text of: "Select the desired format you wish to convert the bas".
I know that all your 'bas' are belong to us, but this seems like they may be taking the joke too far.
Active Directory has two main binary data types I can think of offhand, GUID and SID formats. But it looks like they are focused on GUID format at this point.
The two formats described in Convert To are:
The Byte String is how you might see it the CODE MAP Refresh you see in User Application, whereas the Dashed String is probably more like the GUID format you might see in a DirXML-Associations value. It turns out GUID's actually have a standard format that switches between big endian and little endian representations of the data in the same chunk of the result.
I am sure they have a good reason for the GUID being formatted this way but as you read the description you really wonder why.
I think a nice enhancement would be to support SID format conversion from binary to the S-01-1001010 and so on format.
These four actions are really all variations on a theme. Associations and Entitlements use the same attribute syntax, Path, but with slight variations.
Path syntax has three components, nameSpace (integer 0-4billion), volume (A DN), and path or path.xml. (String)
The nameSpace component in a DirXML-Associations value is 0 for ignore, 1 for associated, or 4 for manual migrate. When you use iManager and migrate from Identity Vault, it writes a value of 4 to the nameSpace component of the drivers DirXML-Associations. For a DirXML-EntitlementRef value, the nameSpace of 0 means revoked, and 1 means granted.
The volume component points at the referenced object. For Associations that is the driver object this applies too. For an Entitlement it points at the actual DirXML-Entitlment object. Thus multiple values of either attribute on a user make sense. Especially in the case of a Group entitlement where it can and most often is, granted many times.
The path or path.xml component is where it gets a bit strange. For Associations this should be a unique value in the remote system so that if you searched on it, you would only get a single response. In eDirectory and Active Directory it is a GUID. Every driver is different and I collected as many examples and explanations for what each driver uses in the article: Open Call – IDM Association Values for eDirectory Objects
The Entitlement case though uses the path.xml which adds a requirement that the string be valid XML.
These tokens, the Assert, Get, Set, and Delete cases all know how to parse the funny format of Path syntax and process the results. You could do all these with the regular attribute tokens but you need to be clever and do a fair bit of it manually and repetitively each time. These are convenience Actions to make it easier and they succeed.
A second useful reference is an article I posted on Cool Solutions, Open Call for useful ECMA functions to use in Identity Manager where I started collecting interesting and useful examples for people to suggest more for the list. So if you have something interesting, add a comment, contact me and I will edit that article to add it in.
A third reference is one I would love to see more people contribute to is a Wiki page about useful User Application ECMAScript examples: https://wiki.microfocus.com/index.php/User_App_ECMAScript_Examples
It seems that everyone who works with User App will come up with a set of functions to make life easier, and I was hoping to get people to contribute a set, so I could make a package, then just add that to User App drivers at the outset to save everyone time. The more contributions the merrier.
Additional changes not listed:
As I was working through these enhancements I noticed some other minor things that were not called out in the readme notes.
Set Variables plural.
I thought this was a clever enhancement. Previously, Set Variables was a single variable at a time. Now you can build a single Action that sets as many variables as you need.
Attribute tables can fold.
I mentioned this earlier but nice to call it out, that there are many places where a table is present. In Set Variables above, one line for each variable. Or in Create User where a long list of attributes is expected to be provided. In all those cases, the table can be folded to save screen real estate.
In addition to big new features, a list of notable bugs fixed is included as well. Most of them are simple and not worthy of discussion. But I will highlight one or two that I think are interesting.
These two I think are worth further discussion:
* Fixed import issue some referenced variables would not be imported
The Import Export functionality is important. I often tell people import all your connectors, get them configured with variables, and then share that JSON file with your project team. Then the GUID's for each connector are defined and thus all tests built will reference them with the same GUID. However it turns out they added an Import/Export function at some point that seems to figure this out reasonably well.
Not only does it seem to better connect to the existing Connectors you have defined, it also exports the variables it references and imports them. Clearly there was an issue in that last step that they fixed.
* Fixed issue in LDAP connector where Delete Objects would only delete 1000 objects
In hindsight this should have been an obvious issue. Most LDAP servers have a search limit, and I am guessing they did a query for users that met the pattern, looped over the values returned and deleted them.
Every time you see an LDAP issue with 1001 objects, which means 1000 worked, one more, not so much you know that this is a search limit thing.
eDirectory in principle could have this problem, but by default ships with a search limit of 0, which means unlimited. (iManager, expand LDAP section, LDAP Options, View LDAP Servers, select an LDAP Server object and on the Searches tab, there are two limits, by entries and by time.) Active Directory has a limit of 1000.
Interesting, LDS (Microsoft's ADAM upgrade) has a limit of 1500 attribute values. This search limit discussed above is a limit on objects that your search filter returns. It does not affect the number of values returned in an attribute, but LDS has a limit of 1500 on the number of attribute values in a single attribute it will return. Very annoying.
As you can see, lots of great stuff in IDM Validator 1.4, stay tuned, I hope to have a book out soon about all the Actions in Validator. If they won't write a manual for it, darn it, I guess I will have too!