We are in process of acquiring a client webservice as an endpoint. They have some audit and compliance requirement that in the soap request , IAM should be able to send the id of the admin who has initiated the transaction on user.
Their is one way of doing it through Px. We can add admin userID to a user attribute after the task is completed, this can be achieved through Px. We can then use this attribute in the soap request.
But it does not seems to be feasible since there would be many transactions going on inside IAM and this policy would have to run on each and every one of them.
Is there any other way of achieving this , maybe by directly using some script/custom code at provisioning side?
Any comments/suggestions are highly appreciated.
Ps:-We are using 12.6SP4 CR4 setup for IDM
Hello,Talking with other colleagues we think this is impossible to record this from provisioning as the way that IM works. In the IM management console when you click on the IME, then advanced, then provisioning; you will see the connection information to the provisioning server. In that connection information is the admin Id. This “Proxy ID” is the ID that is passed from IM to provisioning server when we as the provisioning server to do any work. So the ID performing all tasks is not the user’s manager but the proxy ID that is passed by IM to prov server.
This compliance question has been asked before. The previous answers have been different from everything to report server to adding a custom tracking attribute that holds data related to the last change performed on a user and who performed it recorded in a multivalued attribute on the user’s corp record and synched to that users global account and consumed on an endpoint. Of course we do not help with custom tracking in this manner.
Basically you need to set a policy express policy that listens on task complete of the modify user, reads the task information such as task, initiator, time, date. Then sets and syncs that information on a multivalued attribute that has already been created and mapped in the corp directory.xml. in the same provisioning server settings mentioned above that attribute is mapped to say %UCU01%. Now what happened in IM is captured and saved to global record until the next modify user comes and overwrites it. If they do not want to overwrite it then they have to append to the date in the attribute.But take care, because this can cause synch issues in the future as the data grows outside of what the attribute can hold or longer than the column storing the data in the database.
Hope this helps
Instead of appending the data to an attribute you can use multi-value attribute and just add another value each time. You can then run a cleanup.
Instead of adding just the UserID of the admin who ran the task you can also add the taskID and you'll have all the info needed to know who did what:
AuditAttribute = USER_ID;TaskID
Thanks for reply !!
Having said that we can provision the initiator id to provisioning adopting various methods (like Px or logical attribute ) in the custom attributes , is it possible to make this custom attribute a "capability attribute" at provisioning level?
This is because the initial attributes are sent to provisioning only when they are updated, so suppose if same admin is performing task on a user, the initiator id will not change and then webservice would have to retrieve this custom attribute each time before invoking the WSDL.
Any suggestions here would be appreciated !!
But I have one doubt , I suppose this would have to be setup at each task screen because there are multiple tasks performed on the user in the environment. Kindly correct me I am wrong here .
Well, you can set a PX to run on event (modify user for example) and get the admin's DN (and from that you can pull the userID), and you have some more information,task number (not sure what the value holds), task tag name.
About your other question, as I mentioned, I would have user a combination of initiator and Task information and ADD it to the multi value attribute (instead of SET it) using a PX.
You mentioned you are not sure what "Task Number" does in PX. I have an answer for you.
Task Number is user friendly number to admin task. It is directly one-to-one mapped to Task Session ID. Task Session ID is a very long alphanumeric string and it is not useful if you want to treat it as Ticket Number. Task Number was introduced to provide a user friendly number that can be treated as a Ticket Number that can be tracked and shared with end users. You can also search tasks in View Submitted Tasks using this Task Number.
So in that case, i would build a PX that set this number on every event of user modification \ creation. If the task has sync accounts it will flow to the endpoint with the changes, in that case every transaction will have easy audit.
Yes you will have to add logical/physical attribute where you want to store Initiator's id on each screen and this code as well. There was a typo in the API method in my previous response. Correcting it now.
Alternatively, you can write a global BLTH and use this method to get Initiator's id but you will still have to add logical/physical attribute where you want to store Initiator's id to each task screen.