Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Vice Admiral
Vice Admiral
1718 views

NetIQ REST driver - Custom Handler Hiding Authorization Header Values

Jump to solution

IDM 4.7.3'

We are running NetIQ REST driver with custom handlers, we have added custom header Authorization with api specific scheme and values, we want to hide this info into trace and logs of the driver, how to achieve this?

 

The example below (had to google some example from web to illustrate)

 

<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.3.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<driver-operation-data class-name="judoMonkey" command="custom-query">
<request>
<url-token Service="http://nnn"/>
<header Authorization="Bearer ApiKey xxxxxxxxxx"/>
<value>{}</value>
</request>
</driver-operation-data>
</input>
</nds>

 in this above example header Authorization values is visible in clear text in driver trace.

 

/Maqsood.

 

 

Labels (1)
Tags (1)
0 Likes
1 Solution

Accepted Solutions
Vice Admiral
Vice Admiral

@Vikash Varun  @dstagg 


Thanks for info, it did work, but the response from shim also shows the header, maybe i need to apply this to input transformation same stuff.

only challenge with this is that troubleshooting will be difficult, since we dont see whats going out and coming in  🙂

but thanks for info.

 

/Maqsood.

View solution in original post

0 Likes
17 Replies
Micro Focus Expert
Micro Focus Expert

You need to add an is-sensitive attribute to the header element node:

https://www.netiq.com/documentation/identity-manager-47/driver_admin/data/t45clgjllttj.html

--
Norbert
0 Likes
Vice Admiral
Vice Admiral

@klasen  i tried to add following; 

 

<do-set-xml-attr expression="../driver-operation-data[last()]/request[last()]/header/Authorization" name="is-sensitive">
<arg-string>
<token-text xml:space="preserve">true</token-text>
</arg-string>
</do-set-xml-attr>

this looked fine in trace where it was adde , but the final operation-data which left driver output to shim had still the header values in clear text, same noticed when reply cam back from shim.

 

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.7.3.0">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input>
    <driver-operation-data class-name="users" command="modify" event-id="0" src-dn="zz">
      <request method="patch" url="RESTEndpotin">
        <url-token association="nnn" src-dn=""/>
        <header Authorization="bearer xxxxxx" accept="application/json" content-type="application/json"/>
        <value>{some json data}</value>
      </request>
    </driver-operation-data>
  </input>
</nds>

 

 

0 Likes
Admiral
Admiral

Try with "../driver-operation-data[last()]/request[last()]/header", it will hide the whole header, but should work.

Cheers.

0 Likes
Vice Admiral
Vice Admiral

I tried the suggestion, but it only hides within output policy, as I  earlier experienced, Header values are still visible after output policy is finished and when the last final operation submits to shim.

 

/Maqsood.

0 Likes
Admiral
Admiral

I was afraid of that. Then there is currently no option to hide it. Which is why some people implement a REST driver using either Ecmascript or the scripting driver.

I'd suggest to open an Service Request and get this logged as a bug. 

 

Cheers,

Casper

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

You might be able to do a Java extension, document handler type, and add is-senstive as it comes back out of the shim...

0 Likes
Vice Admiral
Vice Admiral

I have opened bug  at NetIQ. I think if I would go create custom java extension, which i can do, then i could have written whole driver shim myself implementing few java interfaces for subscriber channel to work with apache http client,   so lets hope NetIQ fixes that 🙂

/Maqsood.

0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
is-sensitive = "true" can be passed as an attribute to <driver-operation-data>. Then the header will not be traced before it is handed to shim. We will handle the same for response in REST1.1. The output <driver-operation-data> will get populated with is-sensitive = true too as part of the bug-fix
0 Likes
Micro Focus Expert
Micro Focus Expert

@maqsood, using the suggestion from @Vikash Varun, your action statement should look like:

<do-set-xml-attr expression="../driver-operation-data" name="is-sensitive">
<arg-string>
<token-text xml:space="preserve">true</token-text>
</arg-string>
</do-set-xml-attr>

Is that something you have tried?

In your response to @klasen you indicated you had tried:

<do-set-xml-attr expression="../driver-operation-data[last()]/request[last()]/header/Authorization" name="is-sensitive">
<arg-string>
<token-text xml:space="preserve">true</token-text>
</arg-string>
</do-set-xml-attr>

putting the is-sensitive=true" at the <header> level (which failed) and not the <driver-operation-data> level.

Though as I reread Vikash Varun's post, it might still need the bug fix for the response to be handled as well.

 

0 Likes
Vice Admiral
Vice Admiral

@Vikash Varun  @dstagg 


Thanks for info, it did work, but the response from shim also shows the header, maybe i need to apply this to input transformation same stuff.

only challenge with this is that troubleshooting will be difficult, since we dont see whats going out and coming in  🙂

but thanks for info.

 

/Maqsood.

View solution in original post

0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

There are a couple of things here.

1.) From REST 1.1 you might need not handle it in policy for response. I am changing the implementation so that that if input <driver-operation-data> has "is-sensitive"=true, it will retain that attributes from appshim and will not remove "is-sentive"= true from output as well.

2.) I understand the troubleshooting will become difficult. But the whole idea of driver operation data is to hold only operation data. Not sure of why the Authorization header is being passed in driver operation data. Is there an issue passing it in Authorization header from driver configuration?

/Vikash

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.