Support for Digest authenticated proxy

[srnagar]

azure-core does not support digest authenticated proxy. This may additionally require changes in azure-identity.

Related customer-reported issue - #5372

[joshfree]

Moving this to the January milestone

[alzimmermsft]

Current State of Authenticate Support
In regards to Basic and Digest authenticate

The two HTTP client implementations which we release, based on OkHttp and Reactor Netty, only have support for Basic Authenticate challenges. This is deeply integrated into the construction of the HTTP client when passed ProxyOptions which contain a username and password used to fulfill the challenge.

OkHttp and Reactor Netty do not have native support for Digest Authenticate challenges.

Proposal

1. Implement Digest Handling in Netty and OkHttp HTTP Clients

This would allow for a tighter coupling of HTTP client and handling authentication challenges, with respect to Basic and Digest. This may allow for some optimization where Azure Core doesn't need to handle deserialization before a response to the challenge is made, additionally these HTTP clients already accept ProxyOptions which contains all the information needed to handle both Basic and Digest challenges resulting in no major changes to our API. This has the downside of potential code duplication or the creation of a new helper class which handles Basic and Digest authentication challenges.

There is a few questions around this direction which need to be answered.

• Does Reactor Netty have an interface which handles dealing with authenticate challenges, OkHttp has an interface for this which is already implemented to handle Basic.
• Does the response for successful authentication flow through this code path? RFC 7616 indicates that a server may respond with a Authentication-Info header which may include a new nonce to use upon subsequent authenticate challenges.

2. Implement HttpPipelinePolicies to Handle Authenticate Challenges

This would allow for a generic implementation that would support any HTTP client implementation being used, including non-Netty or non-OkHttp implementations. It has a downside that the response needs to be deserialized by Azure Core before a response to a challenge can be made. Unlike option 1 this does have the ability to snoop the response from the challenge and may attempt to retrieve a Authentication-Info header to handle subsequent challenges properly.

There is a few questions around this direction which need to be answered.

• Azure Core handles HTTP headers through a Map, RFC 7616 indicates that a server may return multiple WWW-Authenticate or Proxy-Authenticate headers, would this be handled appropriately?

[alzimmermsft]

@amishra-dev Could you clarify which portions of the digest authentication specifications (RFC 2617 and 7616) are required for initial support? I have a rough implementation complete which generally matches the RFC specifications but I am having difficulties with the -sess based algorithms that are outlined given that these require the HTTP entity (entity headers + body) to be passed into the digest. This is running into issues when integrating authentication support into Reactor Netty's pipeline, the potential that the request body may not be replay-able (for example stream a download to an upload), and some vagueness on how to create the HTTP entity from the given parts.

I'm wondering if support for -sess based algorithms are required for the initial release of this functionality.

[amishra-dev]

@alzimmermsft I have a setup that I can share with you to test. we just used squid proxy and enabled digest auth in that. I will forward you the mail where the customer lists what they need.