Maltego authentication + key based auth

Hi,
I am using Tyk as the gateway to our internet facing API. My application uses its own generated keys and I have them syncing to Tyk via some custom processes using the Tyk API.

Normal requests hit Tyk with either an Authorization header or GET parameter containing the key which works great, requests go through and come back fine.

My problem is that I also provide a set of Maltego transforms for use with my data and the requests are XML based. I am unable to control the request headers or get parameters from Maltego clients. This results in 401 unauthorized responses as Tyk doesn’t see the key being passed in. Below is a sample request from a Maltego client to Tyk:

POST /maltego/transforms/URLsFromPhrase?Key=5099b67b3dffa8f6c962ca3a710de15e HTTP/1.1
Host: tykgateway
User-Agent: Go-http-client/1.1
Content-Length: 617
Accept: */*
Connection: close
Content-Type: text/XML

<MaltegoMessage>
   <MaltegoTransformRequestMessage>
      <Entities>
         <Entity Type="Phrase">
            <AdditionalFields>
               <Field Name="text" DisplayName="Text">asdfg</Field>
            </AdditionalFields>
            <Value>asdfg</Value>
            <Weight>0</Weight>
         </Entity>
      </Entities>
      <TransformFields>
         <Field Name="Authorization">THIS-IS-MY-API-KEY</Field>
      </TransformFields>
      <Limits HardLimit="12" SoftLimit="12"/>
   </MaltegoTransformRequestMessage>
</MaltegoMessage>

As you can see the authorization field is encapsulated in the XML request.

Can I write a custom plugin to pull the key out of these messages while still using normal Tyk ‘Auth Token’ authorization? Or how would you suggest handling this?

Thank you.

The standard authentication mechanism isn’t fully compatible with custom middleware authentication, I would suggest you take a look at the documentation that’s available here, basically:

a) If you’re using a gRPC plugin it’s not possible to interact with Redis directly (at least not through Tyk, so you wouldn’t be able to check for existing keys this way).

b) The custom middleware authentication will require you to implement your own token validation function and create your own session objects, see this sample.