Let’s see how SAP NetWeaver Identity Management deals with this.
Some preliminary words before I show you what needs to be done in Identity Center. If you look at the table mxi_values in your Identity Center database you’ll notice that there is a column “expirytime”. However, you’ll be looking in vain for something like “validfromtime”. There is no such column. The architects of SAP NetWeaver Identity Management decided to implement attributes which are going to be valid in the future as – guess what – pending values.
This has advantages and disadvantages. I’ll come back to this later. For the moment let’s take the example role from the previous post and add user ULLRICHK as owner, but only as of tomorrow (I’m writing these lines march 5 2010). I’ve written a small job who adds this:
Here again the value assigned to the MX_OWNER attribute as text:
We could also add a valid-to date but this is not needed in our example. Let’s look at how the role Test Role for Kais Blog looks like in the DB after execution of this job:
Missing something? There is an MX_OWNER, but it is the owner we assigned already in the first post. If we search for all pending value objects we’ll find this one:
Remember the first post where I explained the meaning of MX_ATTR_STATE=2? Pending enable. When the MX_VALIDFROM date is reached, the value will be enabled.
If we hadn’t left empty the VALIDTO setting in the toIdentityStore pass above there would also be an attribute MX_VALIDTO.
An interesting exercise is to combine the topic of approvals (previous post) and valid-from-in-the-future (this post). Let’s do a role assignment to our role and let’s make this assignment have a valid from date. Have a look at the UI task below:
This task will provide us a simple UI where we can edit the MXREF_MX_ROLE attribute of the user.
Let’s select ULLRICHK and assign “Test Role for Kais Blog” to him.
And now hit Save. Again, as discussed in the previous post a pending value object is created. It looks as follows:
Let’s check the difference between this one and the pending values from the previous post. First, MX_MODIFY_BY is set, this is basically the mskey of the submitter. Wasn’t there in the examples so far because they were not initiated by a UI task. Second, MX_VALIDFROM is there. Please note that MX_ATTR_STATE is 1 (pending approval). Now you will probably have already guessed what happens when the Administrator approves this, huh?
That’s what it looks like after the approval:
Right, MX_ATTR_STATE has changed to 2, because now this object is pending enable because of the MX_VALIDFROM. Btw I should’ve added a task which removes the Administrator user from the approvers list ,but this is a minor detail and of no significance for this example.
Now let’s come back to my introductory words about how the problem of attributes becoming valid only in the future has been addressed in this product. Imagine it would’ve been solved the same way as the expiry time, with a column in the database table. Now how would you deal with the challenge that you have 2 changes in the future? Let’s say I already know my position will be “CONSULTANT” from January 2011 until February 2011 and “CEO” after that? With pending values you can implement this by simply creating 2 distinct pending values. If there were an additional table column for the valid-to date you would require 2 rows each of which contains one valid-from date and the corresponding value. This is not impossible but it would be more than slightly confusing to have 2 table rows for one attribute if this is a single value attribute. Moreover, every query in the database would have to deal with the possibility of having those time dependant values which would basically make everything much more complex (and cost performance). The way it is is easier: If an attribute is not empty there is a corresponding row in the table, if it is empty, there won’t be such a row and if the value will become valid in the future, there is a pending value.
But there is also one fundamental disadvantage: Imagine you want to create a report about a user. Then you need to take into consideration the existence of such pending values unless you don’t care about what happens in the future. But this will usually not be the case, remember the above example: I have a record in my system for somebody who’s already hired and who’ll start working in the future, then it is very likely that I do care about the values which are valid for this person when (s)he starts his/her work.
Thanks again for reading this. Stay tuned until the next post.