Saturday, July 26, 2008

 

Deleting a User with IDXML

Certain actions (such as creating or removing an LDAP entry) are only available via OAM's 'workflow' engine. A freshly installed OAM system has no workflows configured, thus, no immediate mechanism to affect such actions.

To the newly initiated, discovering the create workflow mechanisms are relatively straightforward. But the delete, however, tends to throw people for a loop at first.

The trick is to create a 'Deactivate User Workflow'. Exactly what this workflow does is up the user building the workflow. You'll find, following the definition of the initial step, three similar action choices:

If your goal is truly to whack the account, choose delete. Otherwise, a choice of disable will set the user account ObUserAccountControl flag to DEACTIVATED (with no human interaction required). By default, the Identity System ignores DEACTIVATED accounts in the user searchbase. The deactivate action accomplishes the same thing but it requires a human participant to actually push the button to confirm the action.

Lastly, if you want to access this 'Delete User Workflow' from IDXML you just need to keep in mind that it is a workflow you are calling. Pay close attention to:
Here is a complete request for calling a Deactivate User Workflow:


<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas-xmlsoap.org/soap/envelope/" xmlns:oblix="http://www.oblix.com">
<SOAP-ENV:Body>
<oblix:authentication type="basic">
<oblix:login>admin</oblix:login>
<oblix:password>test1234</oblix:password>
</oblix:authentication>
<oblix:request application="userservcenter" function="workflowDeactivateUserSave" version="NPWSDL1.0">
<oblix:params>
<oblix:ObWorkflowName>obworkflowid=c60491a5ca0a45668fff08da2f1072d2,obcontainerId=workflowDefinitions,OU=Oblix,OU=apps,DC=company,DC=com</oblix:ObWorkflowName>
<oblix:uid>UID=372af3c1-0c7e-428d-a80a-fae632211489,OU=people,DC=company,DC=com</oblix:uid>
<oblix:noOfFields>2</oblix:noOfFields>
<AttributeParams xmlns="http://www.oblix.com/">
<GenericAttribute>
<AttrName>cn</AttrName>
<AttrNewValue>test</AttrNewValue>
<AttrOperation>REPLACE_ALL</AttrOperation>
</GenericAttribute>
<GenericAttribute>
<AttrName>userStatus</AttrName>
<AttrNewValue>delete</AttrNewValue>
<AttrOperation>REPLACE_ALL</AttrOperation>
</GenericAttribute>
</AttributeParams>
</oblix:params>
</oblix:request>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>


Labels:


Comments:
Mark, I think you got the terms disable and deactivate mixed up. Disable requires no user interaction, deactivate does. Also, as far as I remember, none of deactivate/disable/delete need an explicit commit step.

-Vinod
 
Thanks Vinod. I've corrected the post to reflect those changes. I appreciate your input.
 
I am trying to implement a Reactivate user functionality in OAM, I have created the Reactivate Workflow, Wherein i have created two steps

Step 1. Initiate
Step 2. Activate

Wehn i try to call this Workflow in IDXML using SOAP, I get success with the First Step "Initiate - completed" , I can log in to the User Manager and see that a ticket is create for the Master Admin user, I can process that ticket and user get Reactivated. I want to eliminate the need to log in to the User Manager and process the ticket manually. How can i complete both the Steps using IDXML, i.e Initiate Step and the second step to Activate the user. I can paas Master Admin in the SOAP Message. I will appreciate any help on this.
 
Manoj, I believe, if you use the ENABLE action instead, you will have success. Activate requires human intervention (or SOAP call) to process the ticket whereas the enable completes automatically (changing obUserAccountControl to ACTIVATED). I hope that does the trick for you.
 
Hi Mark,

Thanks so much for Replying to my query, That indeed did the trick and Reactivated the user.
I will really appreciate, if you can point me to some document which describes the purpose of each workflow step in little detail. I wasn't able to find this exact information( Enable step doesn't need human intervention) from the developer/administration guide for COREId. Thanks again.
 
I don't have a resource on-line. The Oracle Access Manager education materials have this well documented if you can find someone who has taken the course. If I get time, that would make for a great addition to this blog which I will consider.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?