Add support for HTTP Basic authentication - #812

General note:

It could a bit of backward compatibility issue for clients. They could expect no HTTP digest for HTTPS connection (as it was required before).

Also for all currently existing profiles using of HTTP digest for HTTPS to be the expected behavior. There were no exceptions before.

General note:

It could a bit of backward compatibility issue for clients. They could expect no HTTP digest for HTTPS connection (as it was required before).

Also for all currently existing profiles using of HTTP digest for HTTPS to be the expected behavior. There were no exceptions before.

Latest changes addresses your concern.

@bsriramprasad what problem are we trying to? I am not a fan of HTTP basic auth, de facto it is equivalent of removing the password. We already had issues in the past with profile Q, I have the feeling we are repeating the story here.

Small provocation: isn't certificate based client authentication enough?

Adding Basic Auth will imply that by mistake vendor will implement HTTP + Basic Auth, you can take this for granted.

@ocampana-videotec

Auth will imply that by mistake vendor will implement HTTP + Basic Auth, you can take this for granted.

Good point! Agreed, and that is why the constraint has to be testable rather than advisory. Profile Q's mitigation was a deployment guidance page. This one is normative and checkable — the updated requirements text is in the PR and explained here for coherent PR discussion

1. Accept preemptive Basic credentials over a TLS-protected connection;
2. Include a Basic challenge only in 401 responses sent over a TLS-protected connection;

• A device that advertises Basic over plain HTTP fails this requirement.

3. Respond 401 with a Digest-only challenge when Basic credentials arrive over a non-TLS connection;

• A device that accepts Basic over plain HTTP fails this requirement;

4. support digest authentication and include a Digest challenge in every 401 response.

• A device that supports Basic-only fails this requirement.

Each requirement maps to a conformance assertion.

isn't certificate based client authentication enough?

mTLS binds authentication to the TLS connection. A gateway terminates TLS, so the client certificate never reaches the device, mTLS did not replace/deprecate digest and continues to be in core. Per-client certificate issuance, renewal, and revocation is also a substantial operational burden.

what problem are we trying to?

The problem we are addressing is interoperability with TLS-only deployments and architectures where Digest cannot be forwarded transparently through a proxy because it is bound to the request URI and server nonce. Mutual TLS is another valid option, but it requires client-certificate provisioning and is not equivalent to username/password authentication for existing clients and deployments.

Authentication mechanisms in ONVIF

Client → Device (inbound)

Device → Authorization Server (outbound)

Defined in the ONVIF Security Service Specification for OAuth 2.0 client registration:

Gap addressed by this proposal. No existing inbound mechanism is simultaneously proxy-forwardable, based on device-local credentials, and free of external infrastructure.

• Digest and TLS client certificates require no infrastructure but cannot be forwarded through an intermediary.
• JWT forwards cleanly but requires an OpenID Connect authorization server.
• WS-UsernameToken is SOAP-only and legacy.

Note on client_secret_basic. ONVIF already specifies HTTP Basic in the Authorization header over TLS as an accepted method for protecting the device's OAuth 2.0 client secret. The security judgement for Basic-over-TLS is therefore already established in the specification; this proposal applies the same judgement to the inbound direction, where TLS provides identical protection.

Bottomline : Basic is the only combination of stateless-forwardable, device-local credentials, and zero infrastructure.