Anonymous_User Absent Member.
Absent Member.
422 views

SOAP Driver does not pick up request headers


Dear everybody

We're trying to provision users to a cloud application and i am
experiencing a strange behaviour. The Shim does not pick up the
information in the operation data, at least not all of it.
Within this solution we first need to send an authentication message
(GET) to one URL. After requiring the AccessToken, the actual
provisioning is send to another URL with the AccessToken.
When i use the driver configuration variables for the subscriber channel
it works, but that will only work for 1 URL.
It is an IDM 401 setup and there are no issues with communication,
networks firewalls etc.

So, first part to show what goes wrong :
The driver submits the following to the shim :

[09/26/14 17:26:38.698]:Concur ST: Submitting document to subscriber
shim:
[09/26/14 17:26:38.699]:Concur ST:
<nds dtdversion="4.0" ndsversion="8.x">
<input>
<modify class-name="User" event-id="0"
qualified-src-dn="O=ACME\CN=xxxxxxxxxxxx"
src-dn="\ACME_IAM4_ACC\ACME\CN=xxxxxxxxxxxx">
<modify-attr attr-name="OATHNToken">
<add-value>
<value type="string">xxxxxxxxxxxx</value>
</add-value>
</modify-attr>
</modify>
<operation-data event-id="1" method="GET">
<request-headers remove-existing="true">
<request-header name="Authorization">Basic
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
<request-header
name="X-ConsumerKey">xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
</request-headers>
</operation-data>
</input>
</nds>


The mod event is fake because the driver will not send empties (although
the configuration is set to do so).
The cloud application seems not mind anyway and ignores the event given
the response.

The response is :


[09/26/14 17:26:38.701]:Concur ST: Concur: Value of Boolean flag
'remove-existing' is : false
[09/26/14 17:26:38.701]:Concur ST: Concur:
HTTPSubscriberTransport.send()
[09/26/14 17:26:38.701]:Concur ST: Concur: Preparing HTTP GET
connection to http://tinyurl.com/lblal8u
[09/26/14 17:26:38.701]:Concur ST: Concur: Setting up SSL
connection..........
[09/26/14 17:26:38.702]:Concur ST: Concur: Setting the following HTTP
request properties:
[09/26/14 17:26:38.856]:Concur ST: Concur: IOExecption : Server
returned HTTP response code: 400 for URL: http://tinyurl.com/pr3ta5n
[09/26/14 17:26:38.857]:Concur ST: Concur: Response code and message:
400 Bad Request
[09/26/14 17:26:38.857]:Concur ST: SubscriptionShim.execute()
returned:
[09/26/14 17:26:38.857]:Concur ST:
<nds dtdversion="2.0">
<source>
<product build="20120601_162440" instance="xxxxxxxxxxxx"
version="3.5.7">Identity Manager Driver for SOAP</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<Error>
<Message>You must provide your consumer key in an X-ConsumerKey
header.</Message>
</Error>
</output>
<operation-data event-id="1" method="GET">
<request-headers remove-existing="false">
<request-header name="Authorization">Basic
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
<request-header
name="X-ConsumerKey">xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
</request-headers>
</operation-data>
</nds>

As you van see, *it DOES pick up the method="GET"*, so that part works.

Authorization header is set to "ignore" in de driver config, so it
should pick up the one in the operation data.
When we configure the Authorization and the X-ConsumerKey in the driver
configuration it does work nicely.
We tried to move the operation data inside the operation but that does
not work either.

The most significant part is the the trace shows : *Value of boolean
flag 'remove-existing' is : false, which it should not.*

So, i moved everything to the driver configuration and move towards the
actual provisioning.
The event submitted to the shim is :


[09/26/14 17:26:38.879]:Concur ST:Submitting document to subscriber
shim:
[09/26/14 17:26:38.879]:Concur ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.0.2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<batch xmlns="http://www.concursolutions.com/api/user/2011/02">
<UserProfile>
<FirstName>xxxxxxx</FirstName>
<OrgUnit1>xxxxxxx</OrgUnit1>
<OrgUnit3>xxxxxxx</OrgUnit3>
<OrgUnit2>xxxxxxx</OrgUnit2>
<OrgUnit5>xxxxxxx</OrgUnit5>
<ACMEIdentityStatus>Active</ACMEIdentityStatus>
<ACMEIdentityType>Personal</ACMEIdentityType>
<OrgUnit4>xxxxxxx</OrgUnit4>
<ACMEPersonType>Employee</ACMEPersonType>
<LastName>xxxxxxx</LastName>
<FeedRecordNumber>1</FeedRecordNumber>
<LedgerKey>DEFAULT</LedgerKey>
<ExpenseUser>Y</ExpenseUser>
<TripUser>Y</TripUser>
<InvoiceUser>Y</InvoiceUser>
<Password>xxxxxxx</Password>
<LocaleName>en_US</LocaleName>
<CtryCode>FR</CtryCode>
<CtrySubCode>Europe/Paris</CtrySubCode>

<SKIP/>

<CrnKey>EUR</CrnKey>
<Custom21>FR</Custom21>
<LedgerKey>DEFAULT</LedgerKey>
<ExpenseUser>Y</ExpenseUser>
<TripUser>Y</TripUser>
<InvoiceUser>Y</InvoiceUser>
<ExpenseApprover>N</ExpenseApprover>
<InvoiceApprover>N</InvoiceApprover>
</UserProfile>
</batch>
<operation-data
url="https://xxxxxxx.xxxxxxx.com:8443/api/user/v1.0/Users">
<request-headers remove-existing="true">
<request-header name="Authorization">OAuth
xxxxxxxxxxxxxxxxxxxxx</request-header>"
<request-header
name="Content-Type">application/xml</request-header>
</request-headers>
</operation-data>
</input>
</nds>

The response is :



[09/26/14 17:26:38.884]:Concur ST:Concur: Value of boolean flag
'remove-existing' is : false
[09/26/14 17:26:38.885]:Concur ST:Concur:
HTTPSubscriberTransport.send()
[09/26/14 17:26:38.885]:Concur ST:Concur: Preparing HTTP *POST*
connection to https://xxxxxxx.xxxxxxx.xxxxxxx:8443/api/user/v1.0/Users
[09/26/14 17:26:38.885]:Concur ST:Concur: Setting up SSL
connection..........
[09/26/14 17:26:38.886]:Concur ST:Concur: Setting the following HTTP
request properties:
[09/26/14 17:26:38.990]:Concur ST:Concur: Did HTTP POST with 1059 bytes
of data to https://xxxxxxx.xxxxxxx.com:8443/api/user/v1.0/Users
[09/26/14 17:26:39.065]:Concur ST:Concur: IOExecption : Server returned
HTTP response code: 400 for URL:
https://xxxxxxx.xxxxxxx.com:8443/api/user/v1.0/Users
[09/26/14 17:26:39.066]:Concur ST:Concur: Response code and message: 400
Bad Request
[09/26/14 17:26:39.066]:Concur ST:SubscriptionShim.execute() returned:
[09/26/14 17:26:39.066]:Concur ST:

Regardless the validity of the actual message (which is REST btw) :

THE OPERATION-DATA
URL=\"HTTPS://XXXXXXX.XXXXXXX.COM:8443/API/USER/V1.0/USERS IS BEING
PICKED UP BY THE SHIM (LOOK AT THE PATH PART)
BUT AGAIN : VALUE OF BOOLEAN FLAG 'REMOVE-EXISTING' IS : FALSE, WHICH
IT SHOULDN'T.
And the request-header name="Authorization" is not used by the shim
resulting in a 400 Bad Request

We tried to move the operation-data around in the XML (inside the
operation) but that doesn't work either.
We cannot use the "multiple" connection in the driver configuration for
the Authorization header is dynamic based on the acquired token.


My big questions :
1) Why does the driver state "Value of Boolean flag 'remove-existing' is
: false" when it should not.
2) What am i doing wrong , or is this a bug.

I can't find any similar on the forum or within the TID's

I hope anyone can help me out here.


Thanks very much in advance !!!

David


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

Labels (1)
0 Likes
8 Replies
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers

dvandermaas wrote:

>
> Dear everybody
>
> We're trying to provision users to a cloud application and i am
> experiencing a strange behaviour. The Shim does not pick up the
> information in the operation data, at least not all of it.
> Within this solution we first need to send an authentication message
> (GET) to one URL. After requiring the AccessToken, the actual
> provisioning is send to another URL with the AccessToken.
> When i use the driver configuration variables for the subscriber channel
> it works, but that will only work for 1 URL.
> It is an IDM 401 setup and there are no issues with communication,
> networks firewalls etc.
>
> So, first part to show what goes wrong :
> The driver submits the following to the shim :
>
> [09/26/14 17:26:38.698]:Concur ST: Submitting document to subscriber
> shim:
> [09/26/14 17:26:38.699]:Concur ST:
> <nds dtdversion="4.0" ndsversion="8.x">
> <input>
> <modify class-name="User" event-id="0"
> qualified-src-dn="O=ACME\CN=xxxxxxxxxxxx"
> src-dn="\ACME_IAM4_ACC\ACME\CN=xxxxxxxxxxxx">
> <modify-attr attr-name="OATHNToken">
> <add-value>
> <value type="string">xxxxxxxxxxxx</value>
> </add-value>
> </modify-attr>
> </modify>
> <operation-data event-id="1" method="GET">
> <request-headers remove-existing="true">
> <request-header name="Authorization">Basic
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
> <request-header
> name="X-ConsumerKey">xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</request-header>
> </request-headers>
> </operation-data>
> </input>
> </nds>
>
> My big questions :
> 1) Why does the driver state "Value of Boolean flag 'remove-existing' is
> : false" when it should not.


1. Your operation data is a sibling node to the modify rather than a child.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


That is correct , when you put operation-data inside the operation it is
removed just for the shim. So keeping is as a sibling will tel the shim
to act. And is does if you look at the method en url attributes.
After doing some testing. it seems that checking for "<request-headers
remove-existing="true">" fails.
There is a known bug that was resolved in the 4.0.0. (a type in the
code) but installing the patch does not solve this issue


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


Hi David,

You should really have it inside the operation your sending for the shim
to act I think. Might be best if you add the operation data nodes in the
OUTPUT transformation to prevent it from being stripped before.

This is how i use operation-data in my custom soap stylesheets, in OT
just before it hits the shim.

Code:
--------------------

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<urn:Login>
<UserName>me</UserName>
<Password>whatever</Password>
</urn:Login>
<operation-data soap-action='"urn:whatever"'/>
</soap-env:Body>

--------------------


Did any fun dives recently?

Regards,

Albert-Jan


--
albertjanstevens
------------------------------------------------------------------------
albertjanstevens's Profile: https://forums.netiq.com/member.php?userid=664
View this thread: https://forums.netiq.com/showthread.php?t=51850

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


Hi Albert-Jan
Yeah..... did some good diving ... wanna join in the near future...;-)
We do have some nice plans.

And for the soap stuff.
When i move the operation-data inside the operation, the xml attributes
of operation-data will work, so in your in example it will work. (BTW,
it is a REST interface, so no envelops), In my trace above the
method='GET' does work.
In my case it also works when i move it outside of the operation 😉

The problem is with the child elements of <operation-data>. The first
one is <request-headers remove-existing="true">

To be more specific, this element is checked by the shim and from what
is see the comparison contains a bug. Looks like is does a string
compare on the whole element instead of an element value compare
There were actually two bugs (if this is one). The other one was a typo
in the method : getRequestHeaderRemoveExistingFlag was spellen
getReuestHeaderRomoveExistingFlag. This was fixed in the 4.0.0. release
of the shim according to the release notes (bug 785549). But it did not
solve our problem.
I even tried xml documents with the operation-data inside & outside the
operation... No success

I came across some documents where somebody stated to change
operation-data to driver-operation-data because for the SOAP shim these
are actually two different things.


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers

dvandermaas wrote:

> I came across some documents where somebody stated to change
> operation-data to driver-operation-data because for the SOAP shim these
> are actually two different things.


The real story is that the SOAP driver was written somewhat incorrectly. Other driver shims shouldn't really ever see operation-data. The engine should remove operation data before submitting it to the shim.
The idea behind driver-operation-data was that this would eventually be the only/correct way to instruct the shim to override the default behvaiour on a per-command basis.

The documentation still refers to operation-data, so you should still be able to use that.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


That explains ;-), thanks for the info! .... Will stick to the
operation-data and hope we'll get it to work


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


Yep, it is a bug (#804765) Working with engineering on the fix. Will
update if solution is there.....


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SOAP Driver does not pick up request headers


Just an update. There is an fix (engineer build)

Operation-data is not used anymore for this. According to old
documentation the SOAPShim should leave the "operation-data" within the
operation untouched but like all other drivers it is removed and it only
worked if this element is left outside of the operation.
In order to use the request-headers overriding a element should be
placed inside the operation called "driver-operation-data" with the
request-header childs.

Second part of the fix is reading the request-headers
remove-existing="true" correctly.
Nice thing is that if you make an error in the Authorization header the
trace will show this header. If it is correct it will not be shown in
the trace.

Last part (not a fix but just not in the documentation), the shim will
decode the authorization header.
So if you add <request-header name="Authorization">Basic
~dest.app.user~</request-header> make sure the var ~dest.app.user~ is in
clear text name:password (please use named passwords)


--
dvandermaas
------------------------------------------------------------------------
dvandermaas's Profile: https://forums.netiq.com/member.php?userid=1956
View this thread: https://forums.netiq.com/showthread.php?t=51850

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.