Can access tokens be validated on SOAP Passthrough proxies configured in Edge?

Not applicable

If so...

- How do we pass in the token?

- How do I retrieve the token in a flow variable?

- Are there examples of this being done that my team can reference?

1 5 1,241
5 REPLIES 5

Former Community Member
Not applicable

There is no standard in SOAP to pass OAuth Access Tokens or API Keys (perhaps there is some field in WS-Security that might be able to accept it), therefore, the SOAP Wizard doesn't allow you to add those policies. Having said that, once the bundle is generated by the wizard, you can manually add OAuth or API Key policies.

You'd pass this in as an Authorization header (Bearer token), right? Or is there a unique mechanism for SOAP passthrough?

I think ..that is an obvious way to transmit the token. It would be really easy for Edge to handle it, extract it, validate it.

The other obvious option is to transmit the token in the SOAP Standard way, using Ws-Security . WS-Security describes 3 standard Ws-Sec header elements: UsernameToken, BinarySecurityToken, and SecurityTokenReference. About SecurityTokenRefernece, the spec says:

...[it] provides an open content model for referencing key bearing elements.

I was never a fan of the style of Ws-* spec language, but what I think is intended by "open content model" is... you can pass any kind of token you like, including an OAuth Bearer token. In the same section of the spec, it says that "Direct References" to external tokens are the most preferred (highly recommended by spec authors, I guess?) kind of SecurityTokenReference elements. Therefore, it would look something like this:

<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
 <Header>
  <Security TokenType="urn:OAuthBearerToken"
      xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <SecurityTokenReference>
      <Reference token="tKUH8ab3Rokm4t6IAlgcdg9yaEw"/>
    </SecurityTokenReference>
  </Security>
 </Header>
  <Body>
    <SomeRequest xmlns="http://api.example.com/foo/bar" />
  </Body>
</Envelope><br>

This is very SOAP-y, and maybe appears offensive to those of us who like REST and the cleaner model. But, this is exactly what WS-Sec intended. I invented a TokenType for the above - and that's allowed and encouraged by the spec. I also invented an attribute with which to pass the token - also allowed by the spec.

Why would you want to do this, instead of just passing things in a header? (Shrug) I can think of only one good reason: it might be easier on the client developer. Some SOAP client libraries might not let the developer pass arbitrary HTTP headers. But SOAP client libraries all should allow extensibility in the WS-Security Header.

On the Edge side, you'd need an ExtractVariables to extract the token, before calling OAuth2/VerifyAccessToken.

If you don't like all of that, you can invent your own sub-Element for the wssec:Security element. Something like this:

<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
 <Header>
  <Security
      xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
      xmlns:custom="urn:my-custom-namespace">
    <custom:BearerToken>tKUH8ab3Rokm4t6IAlgcdg9yaEw</custom:BearerToken>
  </Security>
 </Header>
  <Body>
    <SomeRequest xmlns="http://api.example.com/foo/bar" />
  </Body>
</Envelope>

This is also allowed by the spec.

Former Community Member
Not applicable

If you wanted a "pure" SOAP way of doing it, then it must be a custom token in the WS-Security header. If you are not that worried about such standards, then leaving it in the Auth header will work just fine.