Does Apigee support Digest Authentication?

[gaspar]

Hello
I'm evaluating Apigee because we have to connect to a REST source that unfortunately only uses Digest kind of authentication, btw in Postman everything works fine but its not viable as a middle tier.

The Digest model is really old and almost not in use anymore, but there are certain monopolies (no names) that will just not move to a more modern model because they don't need to.

Basic information on how Digest Authentication works:

With Digest auth, the client sends a first request and the server responds with a few details, including a number that can be used only once (a nonce), a realm value, and a 401 unauthorized response. You then send back an encrypted array of data including a username and password combined with the data received from the server in the first request. The server uses the passed data to generate an encrypted string and compares it against what you sent in order to authenticate your request.

If Apigee does not support it, I will continue to look for alternatives.

Any pointers will be greately appreciated

Thanks
-G

[strebel]

Hi @gaspar, digest authentication isn't supported by one of the built in policies but you should be able to implement it using the Java extension policy as discussed here: https://www.googlecloudcommunity.com/gc/Apigee/Is-there-an-Apigee-policy-for-HTTP-Digest-access-auth...

[gaspar]

Hi @strebel , I don't know how to do that, the article you subquoted is good and describes it well but its a how it works not how to make it work with Apigee.
Doing the Java extension policy myself kind of defeats the purpose of Apigee to a degree because we need a boxed solution not an implementation.

We'll look for other solutions, maybe Mulesoft can handle Digest.

Thanks for your input

[dchiesa1]

---

@gaspar wrote:

With Digest auth, the client sends a first request and the server responds with a few details, including a number that can be used only once (a nonce), a realm value, and a 401 unauthorized response. You then send back an encrypted array of data including a username and password combined with the data received from the server in the first request. The server uses the passed data to generate an encrypted string and compares it against what you sent in order to authenticate your request.

Yes, I guess this is just sort of standard RFC 2617 Digest Auth. As Daniel said, Apigee does not support this with a built-in policy.

Doing the Java extension policy myself kind of defeats the purpose of Apigee to a degree because we need a boxed solution not an implementation.

You wouldn't use Apigee if your ONLY goal was to have support for HTTP Digest Authentication.  The Java extension capability is there in Apigee to allow people who see value in Apigee for other reasons, to ALSO support special security controls - eg old school RFC 2617 authentication - in addition to the standard stuff Apigee supports. 

I understand what you wrote by :We need a boxed solution: , and ... it's really not difficult to produce a Java extension policy.  RFC 2617 is pretty straightforward. There are lots of options but I suppose your one specific vendor does not require ALL of them.  If you gave me some more narrowed parameters, I could write an example Java extension in an hour or hour and a half. By narrowed parameters, I mean, does the server support qop?  Is it MD5-sess or MD5?  Where would Apigee get the user credentials (username and password)?  Would those be per-request or would it be more like a multi-plexed model where Apigee uses a single username/password for a large set of inbound requests.

But we should go through this effort, only if Apigee is interesting to you for other reasons. 

[gaspar]

Hello @dchiesa1 Thank you for your explanation.

Here's the story: The Canadian Real State Assoc. (and the US) has the full property repository exposed by an API which only authentication model is Digest. Our way of thinking (please correct me if I got it wrong) is that Apigee can be a middle man API with a more modern authentication that our modern tools can extract the data from.
Our main problem is that we can't connect directly because of the Digest model. We know what it is and how it works. We also know that it was deemed obsolete in 2011!!  But like any other monopoly, no need to change: If aint broke.. kind of mentality.

If you're serious and feel can make it work (Apigee connects and interacts to a Digest authenticated source ) we should discuss further. Details will be shared with you privately. As mentioned I have a full Postman collection that works perfectly.

Note: I am totally new to Apigee, didnt know it existed, so I could be totally wrong about the capabilities.


let me know your thoughts..

thanks
Gaspar

[dchiesa1]

yes, I'm serious. 

[gaspar]

Hi @dchiesa1 

I've sent you an note with my details via your website.
thank you

[dchiesa1]

I didn't receive anything, as far as I know. 

[dchiesa1]

on further consideration

I think ... if I were solving this problem, and I really just wanted to do the security mediation between something "modern" and the Digest-based authentication that CREA offers now, I'm not sure I would use Apigee for that purpose. Apigee has a broad set of capabilities, including among them the ability to do security mediation of the kind you describe, though as we have already explained, support for Digest authn is not included out of the box and you'd have to write some custom code to make that happen. 

But the Apigee platform does a lot more than that.  So if your requirement is narrow and limited to just security mediation, it might make more sense to do that in a custom written proxy, a little service that you write yourself and host somewhere like Google Cloud Run, or similar. That will result in lower costs and complexity for the solution. 

That's what I would do. 

[shrenikkumar-s]

Hi @dchiesa1 

Do you've an example/POC of this to be done for the simple case of Apigee uses a single username/password with MD5? Could you please help with the same?

[gaspar]

@dchiesa1 
hm...I wonder what made you change your mind...  I thought you wanted to give it a try as a proof of concept that Apigee can do that.

I think Apigee would be the perfect place to host the proxy'ng activity as it has the whole ecosystem to grow. Yes more complex and more expensive but in the end will offer a better and more robust solution than a little service. The information I shared is very specific to the issue I raised, never was the intention to describe the overall scope.

I understand if you don't want to do anything. 

thank you for your comments.
(If you change your mind, you know where to find me)

-Gaspar

[dchiesa1]

If you have a plan to do other things, beyond this security mediation, then by all means have a look at Apigee. 

I didn't find your contact to me. you can direct-message me here - via the buttons in the upper right corner of this web page. 

[dchiesa1]

FYI, I have implemented a callout that performs HTTP Digest authentication. 

I don't have a wide variety of systems to test it against, but it works with the two test systems I found. 

Check it out, I'm interested in feedback for how it works.