Generate Token using WebServicesClient in Rule

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi Experts,

I am trying to generate the IDN accesstoken using the webServicesClient class but I am getting the following exception:
GenerateLoginTest.testProvisioning:51 » Eval Sourced file: inline evaluation of: `` import java.util.HashMap; import java.util.LinkedHashMap; import java.util . . . '' : Typed variable declaration : Typed variable declaration : No static field or inner class: ARG_URL of class sailpoint.connector.webservices.WebServicesClient

Here is my method:

String generateToken() throws Exception {
        String url = baseUrl+"oauth/token";
        String clientId = application.getStringAttributeValue("idnClientId");
        String clientSecret = application.getStringAttributeValue("idnClientSecret");
        String content_type = "application/x-www-form-urlencoded";
        log.debug(ruleName + " - generateToken - url = "+url);
        log.debug(ruleName + " - generateToken - clientId = " +clientId);
        log.debug(ruleName + " - generateToken - clientSecret = "+clientSecret);
        log.debug(ruleName + " - generateToken - content_type = " +content_type);
        WebServicesClient client = new WebServicesClient();
        Map args = new HashMap();
        Map header = new HashMap();
        Map payload = new HashMap();
        List allowedStatuses = new ArrayList();
        //String request = String.format("%s/oauth/token?grant_type=client_credentials&client_id=%s&client_secret=%s", url, clientId, clientSecret);
        String request = url+"?grant_type=client_credentials&client_id="+clientId+"&client_secret="+clientSecret;
        args.put(WebServicesClient.ARG_URL, request);
        header.put("Content-Type", content_type);
        allowedStatuses.add("200");
        allowedStatuses.add("201");
        log.debug(ruleName + " - generateToken - request = " +request);
        client.configure(args);
        try {
            String response = client.executePost(request, payload, header, allowedStatuses);
            log.debug(ruleName + "WSlookup - Authenticate - response: " + response);
            Map responseMap = JsonUtil.toMap(response);
            String accessToken = (String) responseMap.get("access_token");
            log.debug(ruleName + "IDN Authentication successful- got accessToken");
            return accessToken;
        } catch (Exception e) {
      log.error(ruleName + " - Exception generateToken!!");
      e.printStackTrace();
        }
    }

Any suggestions?

2

hey @tamalika01 , if you’re using this rule inside a before Operation you dont need to
create the Webservices Client class object, as it is already in there. Also because you name the Webservice class as client. you should use client.ARG_URL.

Best!

1 Like
3

Hi @ipobeidi ,

thanks your your repose, do you know if this rule will work in a before provisioning rule for AD? is the client object also implicit in other rules?

4

This is a differentsituation. For an AD before ,provisioning you’re going to have a different set of arguments available.
For doing a rest api call you need to build everything from the authentication to the api call. the rule you presented will not work.
Unless you get the application Object of the webservices and use it to create the client.

5

@ipobeidi I see, thanks. What I was trying to do is the following: Store the last generated sAMAccountName in a Transform object. Make an HTTP request to IDN to get the last generated sAMAccountName, increment to the next sAMAccountName for that user, then make a REST call again to Update the tranhsform with the current name… and so on. I was planning to run this logic to generate the sAMAccountName in the AD Before Provisioning Rule. But the REST Client object is not implicitly available in these types of rules.

I will take a new approach now:
store the last generated sAMAccountName in the application object. Use the AD BeforeCreate rule to access the application object and then generate the next sAMAccountName and pass on to the provisioningplan. Then update the application object back again with the new sAMAccountname value. - this I have to see if it works and is feasible

6

You can use the IDN context to do a search in IDN and also in taget soources. you dont need to do a HTTP request for that.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.