In most cases, organizations that implement Identity Management (IdM) solutions identify individual users and associated accounts/access by assigning a unique identifier. These identifiers are non-expiring, non-reusable values, often assigned by an HR system.
The value of these identifiers is that they never change over time. Marriage, divorce, transfer, rehires, etc., have no impact on these values. Once assigned, that single value is forever linked to that person/user/account. This means that no matter how many times that account has a change in surname, login ID, email address, or any other value, that unique identifier (usually known as employee ID or workforce ID) is always the same as it was on the day the account was created.
However, there are times when users/accounts need to be created inside an IdM system, but outside of an HR system. These accounts/objects do not get the standard HR assigned employee ID value because they are created outside of the standard process that generates and assigns that value. This creates a gap in systems where accounts can be created but not associated to a unique identifier to easily find that account later, even if the account has undergone several name changes, etc.
Fortunately, within the NetIQ/MicroFocus Identity Manager (IdM) product, there is a tool that allows you to automatically assign unique values to non-HR-based accounts. The NetIQ IdM product includes a driver/connector called “Identity Provider,” and this driver’s sole purpose is to generate, assign, and track these values within the IdM environment.
There are multiple ways that this driver can be used to assign these values: the ID Provider driver assigns the value directly, the ID Provider driver can be called using REST (like from a workflow or external source), OR, as we will discuss in this article, using XPath to call the ID Provider driver from another driver within the IdM environment.
All options work equally well if the required ports are available (as required by the specific call approach,) so there is no advantage to gain using one over the other, and there are no additional features available to one but not the others. The approach you use is ultimately up to you and the specific design and requirement elements of the solution being implemented. This article will only discuss calling the ID Provider driver from another driver.
The first thing you need to know before trying to call this driver is that it does require the ID Provider driver to be fully configured. The main thing to configure are any ID policies that you may need to call in your other driver(s).
ID Policies are basically simple rule configurations that determine minimum values, maximum values, prefixes, fill criteria (e.g. leading 0’s. i.e. 0000002345), and most importantly for this article, Access Control.
The min/max values are numerical values that can range from 0 to 2147483647 (2,147,483,647). That’s a lot of numbers that can be used!
The prefix just allows you to require that numbers need to have a prefix of “c”, “t-“, or “visitor”, etc…, in case you wanted to have different numbers assigned for different account types. However, the ID policy cannot be assigned multiple prefixes that are determined dynamically. That is something that would need to be done via standard driver logic in rules.
The Access Control is an enabled/disabled checkbox that essentially determines if the ID policy is available outside of the ID Provider driver. If you are calling this ID policy from anything but the ID Provider driver rules then this must be checked. And, since this article is about calling these ID policies from other drivers, for this solution to work this field should be set to enabled.
Another part of the Access Control settings is the ACL field. This is typically the driver’s name as it appears in your Designer project. Take note of this value as it is critical in the XPath call to be used from the requesting driver logic.
You can create as many different ID Policies as you want with the ID Provider driver. The only requirement is that each ID policy has a unique name. There are also some default policies that come with the driver for quick development purposes.
Beyond creating the ID Policies, you will also need the server IP address of the IdM server that the ID Provider driver will be running on (it does have to be running to work,) and the ID Provider port (default port is 1199). Generally, these values are assigned as Global Configuration Variables (GCVs) for easy reference and future maintenance.
With the ID Policies created and the ID Provider driver details recorded, we are ready to get ID values from other drivers.
Regardless of whether you want to assign the value directly to the object or assign the value to a local variable for additional processing, the same XPath command can be used to get the next value: “id:getNextID($idprovider.ip,$idprovider.port,’ContractorID’,’ID-Provider’,$idprovider.trace)”
id:getNextID is the API call to the driver so it knows to get the next ID from whatever ID policy is being called.
$idprovider.ip is a GCV that stores the IdM server IP address that is hosting the ID Provider driver that is being called. This can be the actual IP address instead of a GCV but a GCV is the recommended approach for future development/maintenance purposes.
$idprovider.port is a GCV that stores the ID Provider port (1199). The port can be statically specified instead of a GCV but GCV is recommended.
‘ContractorID’ is the ID Policy name created in the ID Provider driver. Each ID Policy requires a unique name and that unique name goes here to tell the id:getNextID command which policy to apply.
‘ID-Provider’ is the value in the ACL field of the ID Policy configuration screen. It is typically the driver name and the same for all ID Policies but it must be specified here.
$idprovider.trace is a GCV that specifies what trace level is expected with this call. This can be a static value or GCV and can be set to your preference.
By using the full XPath command from another driver’s rule, you can easily assign unique IDs to accounts. However, there are a few downsides to be aware of….
The ID policies only track the last value assigned by that policy. This means that if I have a min/max range of 0-10 and the policy has assigned 0,1,2,3,4,5 that it will automatically assign 6 as the next number, even if I manually assigned 6 to another object. The ID policies do not do any validation, they only sequentially assign the next number in the policy settings.
With that said, there is a way you can update the ID policy to show the last number assigned. However, if numbers are manually assigned randomly or numbers from other policies contradict numbers from this policy, you may experience issues depending on which attribute the value is being assigned in the IdM environment and/or connected systems.
In the end, the ID Provider driver makes it quick and easy to assign unique identifier values within the IdM space as part of any automated provisioning process and can even have logic applied to it as part of the provisioning process to assign different values based on different ID Policies and/or other rule logic in your other IdM drivers.