• State Not Answered
  • Replies replies
    8
  • Subscribers subscribers
    26
  • Views views
    447
  • Users 0 members are here
  • Locked Locked
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SOAP Driver does not pick up request headers

MigrationDeletedUser

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="">www.concursolutions.com/.../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="">xxxxxxx.xxxxxxx.com:8443/.../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=\"XXXXXXX.XXXXXXX.COM:8443/.../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

Parents
  • 0
    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 in reply to MigrationDeletedUser

    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 in reply to MigrationDeletedUser

    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="">schemas.xmlsoap.org/.../">
    <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

Reply Children
  • 0 in reply to MigrationDeletedUser

    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
  • 0 in reply to MigrationDeletedUser
    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 in reply to MigrationDeletedUser

    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 in reply to MigrationDeletedUser

    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 in reply to MigrationDeletedUser

    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

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.