Obfuscate encrypted data in outbound REST message via script

[Ed41]

I've had a request come across my desk to integrate with a 3rd party tool via REST, but the catch is I need to make rest calls to the target system as part of the form population based on the changes to fields in the form.  This part I have working, but the 3rd party tool in question requires that the username/password for authentication be passed in the body of the rest message to get an authentication token for future calls.  When doing this, there is a plain text version of the password recorded in the ecc queue logs (we use internal mid servers for integrations like this).  Obviously, our information security team will have a problem with that as anyone with access to the ecc queue logs would be able to retrieve the password used for the target system.  If I were doing this in a workflow, I could set an input as an encrypted input, pass the encrypted value to the custom REST activity, and then ServiceNow would internally decrypt the data, make the rest call, and obfuscate the encrypted data in the logs (shows encrypted strings prefixed with [SNC_ENC_VAL] instead of the actual value).  The token returned can then be used in the workflow for subsequent calls, and a logout processed after the fact rendering the token useless immediately following.  Since I'm doing this with a form however, calling a workflow and returning a token doesn't seem like something that I can achieve easily.  I haven't yet converted over to flow designer for everything, but my experience with that suggests that I'm going to run into similar issues retrieving the token for use via a form. 

Ideally I'd like to do with with a script using RestMessageV2, but I haven't yet found a mechanism to securely pass the encrypted data.

Any thoughts on how I might go about achieving this?

[Richard Hine]

Ed,

This sounds like a version of an OAuth token grant...

Does the third party support any form of two step authorization where you submit your creds to them in a basic auth message, receive the token back and then use that token in the authorization header for subsequent messages?

I would be really surprised if they expect the u/pw in plain text... are you able to share what the 3rd party tool is as there could be many different approaches to this...

Thanks,

Richard

[Ed41]

You are correct, it's a 2 step process.  First, submit the username/password in a POST call which returns the token, then the token is used in the header of subsequent calls.  The product in question is Tableau, and what I found very odd about this product in particular is that the username and password are part of a "credentials" object that also contains the "site" you are trying to get to (see sample below from the api docs).  Passing the credentials object without the site object within it results in an error.  The entire thing just seems odd to me, but so far alternative attempts to authenticate have all failed.  The full tableau api docs can be found here for authentication, maybe there's something I missed.  

After I posted this I did start looking at flow designer and it appears I can have flow outputs to pass a token back to my script after executing the flow.  I'm going to take a stab at that, but any suggestions would be appreciated.  I'm not keen on re-inventing the wheel if someone else has done this before (potentially more elegantly than I).

{
  "credentials": {
    "name": "admin",
    "password": "p@ssword",
    "site": {
      "contentUrl": "MarketingTeam"
    }
  }
}

[Ed41]

Just as an update, I did investigate the flowAPI and while the docs indicate you can retrieve outputs from subflows (https://developer.servicenow.com/dev.do#!/reference/api/rome/server/sn_fd-namespace/ScriptableFlowAP...) that you execute I'm having trouble getting that to work.  The output object I get back has the token variable, but the value is set to null.  I've confirmed via the flow designer execution that the token was retrieved successfully and set as an output, but for some reason the flowAPI return isn't seeing that data.

[Ed41 · Accepted solution]

After fighting with the flow API trying to get outputs from the subflow and getting nowhere I decided to try using the executeAction option instead of executeSubflow.  While I wasn't able to pass the token directly as an output this way for some reason (I was using the built-in JSON parser, but it never set the output using the pill picker) I was able to pass the full JSON response as an output successfully and then parse the token out in my script include.  The end result was as follows:

1. an onChange catalog client script triggers a GlideAjax call to a script include.
2. The script include retrieves the credential record, then sets up the action input object and calls executeAction as described here: https://developer.servicenow.com/dev.do#!/reference/api/rome/server/sn_fd-namespace/ScriptableFlowAP....  The password is passed without decrypting it as one of the inputs, and the flow execution shows that the password is masked during processing.
3. The script include parses the token out of the response and passes it back to the client script.
4. The client script stores the token in the form scratchpad (g_scratchpad), which can be referenced by further client scripts for subsequent calls based on additional field changes.