We have a strange situation that one of our developers has noticed with the Basic Authentication policy.
We have it set up to take a username and password:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <BasicAuthentication async="false" continueOnError="false" enabled="true" name="Basic-Authentication-1"> <DisplayName>Basic Authentication 1</DisplayName> <Operation>Encode</Operation> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <User ref="request.queryparam.username" /> <Password ref="request.queryparam.password" /> <AssignTo createNew="false">request.header.Authorization</AssignTo> <Source>request.header.Authorization</Source> </BasicAuthentication>
When we set up a log policy to watch the requests happen we see output that looks like this:
UID PW Negotiate TlRMTVNTUAAAADw==
UID PW Basic dGVuvcjk=
UID PW Negotiate TlRMTVNTUAAAADw==
UID PW Basic dGVuvcjk=
UID PW Negotiate TlRMTVNTUAAAADw==
We are not sure what is causing this and would love some help as this is - well - causing authentication problems with our backend system on every other call!
Thanks!
I'd love to be able to help out, but it's hard to know just what is going on, without more information. One possibility: the original caller sends in a request wand the backend is returning an Authorization: Negotiate header as per the SPNEGO extensions from Microsoft (See https://msdn.microsoft.com/en-us/library/ms995330#http-sso-2_topic1 ) The original caller then correctly responds to that header by sending in a Basic authorization header with username/password contained therein. If this is the case, then the solution might be to configure the proxy to strip the Authorization: Negotiate header from the response before it is sent to the original caller.
But to really know, you'll need to do some further diagnosis .
Hi @Dino. I am going to try to give a bit more context here. We have set up a really basic proxy that calls a MS backend service (of course!) that takes in input like this: http://<apigee-url>/proxy-name/attempt?username=USERNAME&password=PASSWORD
The proxy its self is almost as simple:
1) it uses a basic authentication policy to generate a basic authentication token
2) it logs request.queryparam.username, request.queryparam.password, & request.header.Authorization out to disk
3) it wraps the request.header.Authorization in a soap request to the backend.
Thats it.
As you can see from my log output - the proxy seems to be generating the wrong kind of request.header.Authorization every other attempt.
I am just trying to figure out under what conditions that might happen.
User | Count |
---|---|
7 | |
2 | |
2 | |
1 | |
1 |