Apigee Basic Authentication mechanism

Not applicable

Hi,

We are migrating Layer 7 to Apigee. During migration we noticed, users are facing issues with Basic Authentication.

In Layer 7 if we are hitting the url in the browser without authorization then it is asking for username password in the popup, so s supported in SOAPUI. But in apigee we are getting an error if Basic Authorization header is missing.

Can the same achieve in Apigee? Lot of applications are failing because of this reason, so we had to rollback.

Any help is appriciated.

Solved Solved
0 4 564
2 ACCEPTED SOLUTIONS

I am guessing the Layer7 gateway is responding to the unauthenticated request (no Authorization header) with a WWW-Authenticate header. The response header probably looks something like this:

WWW-Authenticate: Basic realm="your realm here"

Then, SOAP-UI receives this response and prompts for username/password. This is just a guess.

Also I'm guessing that there is no logic in the Apigee proxy to send the same header. in that condition, and that's why you see the difference in behavior.

The fix is to get Apigee to respond the same way the Layer7 device responds, when there is no Authorization header.

Advice: Use a trace tool to find out exactly what Layer7 is sending, and then configure Apigee to Conditionally send back the same header (probably with RaiseFault) when the Authz header is missing.

View solution in original post

Not applicable

Finally able to replicate same as Layer 7. Added one raise fault which will trigger when the Authorization header is missing. And the response header in the raise fault is WWW-Authenticat with value Basic realm="myvalue". after the raise fault the basic authentication and next LDAP authentication policy added. In response added the proper content type header as that was creating some issue to give response. Now this asks me to enter credentials in all browsers.

View solution in original post

4 REPLIES 4

I am guessing the Layer7 gateway is responding to the unauthenticated request (no Authorization header) with a WWW-Authenticate header. The response header probably looks something like this:

WWW-Authenticate: Basic realm="your realm here"

Then, SOAP-UI receives this response and prompts for username/password. This is just a guess.

Also I'm guessing that there is no logic in the Apigee proxy to send the same header. in that condition, and that's why you see the difference in behavior.

The fix is to get Apigee to respond the same way the Layer7 device responds, when there is no Authorization header.

Advice: Use a trace tool to find out exactly what Layer7 is sending, and then configure Apigee to Conditionally send back the same header (probably with RaiseFault) when the Authz header is missing.

The header I see in the trace is Authorization only.

Can you help with what change I need to do to get a similar response?

Will raise fault prompt for credentials and once entered will request to the api again with header?

I tried the same. can you give an example fo WWW-Authenticate value?

I tried with value as Basic only. It prompts me for username and password in internate explorer but is ot working in cheome.

Not applicable

Finally able to replicate same as Layer 7. Added one raise fault which will trigger when the Authorization header is missing. And the response header in the raise fault is WWW-Authenticat with value Basic realm="myvalue". after the raise fault the basic authentication and next LDAP authentication policy added. In response added the proper content type header as that was creating some issue to give response. Now this asks me to enter credentials in all browsers.