As I have discussed before, most enterprise organizations enforce some sort of policy for setting up the user's unique identifier. This value is typically used as the primary login ID and reference for the majority of connected systems. It is the task of the Identity Management solution to ensure that this identifier is:
Properly constructed, tested to be unique, and ultimately used in provisioning, update, reconciliation and de-provisioning tasks throughout the user's IdM life cycle.My previous blog Creating Unique MSKEYVALUES in Netweaver Identity Manager went into detail about how NetWeaver Identity Manager (NW IDM) can be used to create, maintain and provision entries in this manner, using NW IDM's MSKEYVALUE attribute. In particular it dealt with the concept of doing this from an automated feed, which is normally sourced from a HCM system. However, there are use-cases where the user might not be added to the system from a feed, but rather is created manually. There are a couple of situations under which this may occur.
- Part-time/temporary/seasonal employees
- Contractors, vendor representatives and others with need of system access who are not employees
In this case, since these identities are not sourced from the HCM system they do not appear in the feed and therefore are not covered by any automatic or audited process and are therefore susceptible to all the issues that have been addressed by implementing an IdM system. Therefore, the creation of manual entry functionality in NW IDM using a workflow is the ideal solution to address this issue. In essence Identity Manager itself is made to be the system of record for these employees and can control and audit the process.
To do this, it is necessary to create a simple workflow screen, using an ordered task group that contains the attributes required for provisioning which would look something like:
The interesting item to note here is that the MSKEYVALUE attribute is not selected! In version 7.0 of NetWeaver Identity Manager, if the MSKEYVLAUE is not selected when "This task creates a new entry" is selected; the administrator is queried to see if this is actually what is desired.
If "No" is selected, then NW IDM will add in its own generated value, in the form of MX_xxxx, where xxxx is a sequential numeric value.
However, it is likely that this system generated MSKEYVALUE will not be suitable for your organization's operations. However, by using an included NW IDM scripting function this value can easily be replaced with your desired value.
To start this process, start your ordered task group with a "to generic pass". We use the "to generic" rather than "to identity store" or even "to database" as it requires the least amount of parameters and can be more finely focused for our needs. We will need two attributes in the pass, MSKEY and another attribute that will hold the new value to be pushed into MSKEYVALUE. Our task will also contain a "RenameEntry" script that uses the uIS_SetValue function to do the rename operation.
The following piece of JavaScript will then change the MSKEYVALUE represented by the passed value for the supplied MSKEY with the value that is contained in the attribute NEWNAME.
function RenameEntry (Par)
{
var mskey = Par.get ("MSKEY");
var newname = Par.get("NEWNAME");
renameResult = UserFunc.uIS_SetValue (mskey, 0, "MSKEYVALUE", newname);
// insert some errorhandling on renameResult here if you'd like
}
This example uses a very simple script that uses the NW IDM ufunction uIS_SetValue. This is a particularly helpful function that allows a task to set a value for a given entry. This function takes four parameters:
- The MSKEY of the entry to be processed
- The Identity Store that this value can be found in
- The name of the attribute to be updated, in this case it is MSKEYVALUE
- The new value for this attribute
We want to be very careful that it is the MSKEY that we are passing here and not the MSKEYVALUE that we wish to change. The main difference to note here is that the MSKEYVALUE is the external facing unique value for the Identity Store, while the MSKEY is the internal value used in the database. Every entry in the Identity Store database has a MSKEY identifier associated with it.
It's also interesting to note the use of the Par.get method. NetWeaver Identity Manager maintains a "data dictionary" of the entry referred to by the value passed in Par. This is a great method for accessing other attributes for an entry passed in a script.
As indicated in the code snipped above, production versions of this script would most likely have some housekeeping functionality and robust error / bounds checking. Additionally the UserFunc.uIS_GetValue function could also be used for lookups in creating the new MSKEYVALUE. However this script does an adequate job of demonstrating the technique under discussion.
Please feel free to comment on this posting or via SDN if you should have any questions on this posting and the techniques that have been covered.
