diff --git a/doc/Core.xml b/doc/Core.xml
index 7328e75a3..ba04068f9 100644
--- a/doc/Core.xml
+++ b/doc/Core.xml
@@ -553,6 +553,8 @@
<>RFC 7616, HTTP Digest Access Authentication<>
+ RFC 7617, The 'Basic' HTTP Authentication Scheme
+ <>RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)<>RFC 3548, The Base16, Base32, and Base64 Data Encodings
@@ -2270,11 +2272,35 @@ DATE: when response was generated
TLS client authorization and
+
+ Devices supporting HTTP Basic authentication according to [RFC 7617], only over
+ TLS-protected connections, and
+ Devices supporting JWT client authorization based on [RFC 6750], only over
HTTPS.
+ A device that supports HTTP Basic authentication shall signal the HttpBasic capability
+ as true and shall:
+
+
+ accept a request carrying an Authorization header using the Basic scheme over a
+ TLS-protected connection, even if no challenge was sent;
+
+
+ include a Basic challenge in the WWW-Authenticate header of each 401 response
+ sent over a TLS-protected connection;
+
+
+ respond with 401 and a WWW-Authenticate header offering only digest authentication
+ when Basic credentials are received over an unprotected connection;
+
+
+ support digest authentication and include a Digest challenge in the
+ WWW-Authenticate header of each 401 response.
+
+ If server supports both digest authentication as specified in [RFC 2617] and the user name token profile as specified in WS-Security the following behavior shall be adapted: a web service request can be authenticated on the HTTP level via digest authentication [RFC 2617] or on the web service level via the WS-Security (WSS) framework. If a client does not supply authentication credentials along with a web service request, the server shall assume that the client intends to use digest authentication [RFC 2617], if required. Hence, if a client does not provide authentication credentials when requesting a service that requires authentication, it will receive an HTTP 401 error according to [RFC 2617]. Note that this behaviour on the server’s side differs from the case of supporting only username token profile, which requires for this case an HTTP 400 error on the HTTP level and a SOAP:Fault env:Sender ter:NotAuthorized error on the WS level.A client should not simultaneously supply authentication credentials on both the HTTP level and the WS level. If a server receives a web service request that contains authentication credentials on both the HTTP level and the WS level, it shall first validate the credentials provided on the HTTP layer. If this validation was successful, the server shall finally validate the authentication credentials provided on the WS layer. summarizes the authentication of a web service request by a server over HTTP and HTTPS.
@@ -2290,7 +2316,13 @@ DATE: when response was generated
JWT client authorization should only be used over TLS secured connections, in order to
protect bearer tokens against replay attacks.An ONVIF compliant device should authenticate an RTSP request at the RTSP level. If HTTP is used to tunnel the RTSP request the device shall not authenticate on the HTTP level.
- When authenticating RTSP or HTTP methods, an ONVIF compliant device shall use digest authentication [RFC 2617] or JWT-based authorization. The credentials shall be managed with the GetUsers, CreateUsers, DeleteUsers and SetUser methods. If the device also supports WS-Security, the same set of credentials shall be used.
+ When authenticating RTSP or HTTP methods, an ONVIF compliant device shall use digest
+ authentication [RFC 2617], HTTP Basic authentication [RFC 7617] over TLS-protected
+ connections or JWT-based authorization. The credentials for digest and HTTP Basic
+ authentication shall be managed with the GetUsers, CreateUsers, DeleteUsers and SetUser
+ methods. If the device also supports WS-Security, the same set of credentials shall be
+ used. The parameters used to validate JWT-based authorization shall be in accordance to
+ the ONVIF Security Service Specification.Authentication over SCTP
@@ -3262,7 +3294,7 @@ onvif://www.onvif.org/name/ARV-453
-
+ Security
@@ -3296,6 +3328,15 @@ onvif://www.onvif.org/name/ARV-453
Indication if the device supports the HTTP digest authentication.
+
+
+ HttpBasic
+
+
+ Indication if the device supports HTTP Basic authentication according to
+ [RFC 7617], only over TLS-protected connections.
+
+ X.509Token
@@ -9729,6 +9770,53 @@ http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet
better understanding.
+
+ HTTP Basic authentication over TLS-protected connection
+ The following exchange between client and device over TLS-protected connection
+ demonstrates a device supporting HTTP Basic authentication according to [RFC 7617] in addition
+ to digest authentication.The initial unauthenticated request and challenge are shown for
+ completeness. A client is not required to wait for a challenge before supplying Basic
+ credentials; it may include the Authorization header in its first request.
+ Unauthenticated request from the client:
+
+
+
+
+]]>
+ Response from the device challenging for authentication
+
+ Authenticated request from the client, using HTTP Basic authentication
+
+
+
+
+]]>
+ Response from the device, rejecting invalid credentials
+
+ Revision History
diff --git a/wsdl/ver10/device/wsdl/devicemgmt.wsdl b/wsdl/ver10/device/wsdl/devicemgmt.wsdl
index 374b8d98c..bca540f8f 100644
--- a/wsdl/ver10/device/wsdl/devicemgmt.wsdl
+++ b/wsdl/ver10/device/wsdl/devicemgmt.wsdl
@@ -227,6 +227,11 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO
Indicates support for WS over HTTP digest authenticated communication layer.
+
+
+ Indicates support for WS over HTTP basic authenticated communication layer according to RFC 7617 for TLS-protected connections.
+
+ Indicates support for WS-Security REL token.