If you are going to call IDM via SOAP to create a new resource request, you should prepare a call like this one:

       String response = userappResourceService.requestResourceGrant(resourceDn, 
            requesterDn /*requester*/, 
            userDn, 
            "request Description",            
                requestParams, /*ResourceRequestParam[] requestParams*/
            null /*String correlationId*/ );
        return response;

As outlined in the guide.

The parameters are described below:

resourceTarget specifies the target resource DN.

requester supplies an identifier for the remote client application making the request to grant the resource.

The requester parameter on this SOAP endpoint identifies the originator of the request. This value is set in the resource request object nrfOriginator attribute, following this convention:

For a SOAP call: "REMOTE_CLIENT:<requester param value>"

For a workflow action: "WF:<wf process id>"

For the user application user interface: "USER_APP"

userTarget specifies the DN for the being granted the resource.

reasonForRequest provides a reason for the request.

requestParams provides the parameter values for the request.

correlationId specifies a resource assignment request correlation ID; if the parameter is null, a correlation ID is generated.

You cannot set the nrfRequester attribute with an external call. If you try to pass as <requester param value> a valid dn, this is not used/passed to the nrfRequester attribute. The purpose of the "requester" parameter seems to be another. This means that every call started outside the User Application interface are done from an administrative user, the one that you are using to authenticate via SOAP. Maybe there is a way to make use of <requester param value> but it if it is so, it is not documented.

If your environment allows to initiate resource requests from outside, it would be nice to track who has really done the request.

In this article we will see a way to request an IDM resource on behalf of any other user and write it on the right attributes.

First of all we have to define a parameter on our resource to pass the requester.





Your resource definition under an ldap perspective will have this ldap attribute:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<parameters>
    <parameter hide="false" binding="dynamic" multivalue="false" instance="false">
        <key>param1</key>
        <display xml:lang="en">
            <label>Requester</label>
        </display>
        <type>String</type>
    </parameter>
</parameters>

Now that we have defined a provisionable parameter, we have to modify the soap request in order to send all the data:

        ResourceRequestParam[] requestParams = new ResourceRequestParam[1];
        requestParams[0] = new ResourceRequestParam("param1",requesterDn);
        String response = userappResourceService.requestResourceGrant(resourceDn, 
            "AnythingYouWantOnFieldNrfOriginator" /*requester*/,
            userDn, 
            "request Description",            
                requestParams, /*ResourceRequestParam[] requestParams*/
            null /*String correlationId*/ );
        return response;

In my case, the resources has to be approved by someone. So I decided to put the logic to fix the nrfRequester attribute inside a custom Workflow.





The mapping activity has one row.

Source expression:

function newRequester(){

   //Read the dynamic field passed via SOAP call
   var tempRequester = NrfResourceRequest.getDynamicParameterValues().get(0).get("param1");
   //If the parameter is valued
   if (tempRequester != null && tempRequester != ""){ 
    //If the parameter is multivalued take the first one, we need a string
    if (!(typeof tempRequester === "string")) tempRequester =  tempRequester.get(0);
    //Transform the string into an LdapName instance and set the requester
    NrfResourceRequest.getResourceRequest().setRequester(new Packages.javax.naming.ldap.LdapName(tempRequester));   
   }
   //Read the requester, if not explicitly passed it will remain the administrative user who made the call
   return NrfResourceRequest.getRequester();
}
newRequester();

Destination Expression:

flowdata.nrfResourceRequest/requester

Thanks to this mapping activity, now the Approval workflow will show the right requester.





But we have even to update the nrfResourceRequest ldap object, because when an administrator/manager approve an assignment, the value written inside nrfAssignedResources comes directly from the ldap object that represents the request.

For this reason we have to define a new Entity on the Directory Abstraction Layer.





The purpose of the Custom entity Activity named "Update Request" inside our custom approval workflow is to update the object.





Now from the resource catalog you can see the right requester.





And the nrfAssignedResources is correctly updated.

cn=MY RESOURCE NAME,cn=ResourceDefs,cn=RoleConfig,cn=AppConfig,cn=UserApplication,cn=Driverset,o=services#1#<assignment><start_tm>20140828151540Z</start_tm><req_tm>20140828140541Z</req_tm><inst-guid>972da98aed524558986999653b6bd738</inst-guid><req>cn=NATAN SANSON,ou=users,o=acme</req><req_desc>request Description</req_desc><parameter><value parm-key="param1">cn=NATAN SANSON,ou=users,o=acme</value></parameter><cause><type>user</type></cause></assignment>

Hope this helps someone with my same requirement.