4 Security

In any communication protocol—especially one carrying sensitive, private data—security is a major concern. From RFC6455, we can see that the WebSocket specification itself does not provide much guidance:

10.5. WebSocket Client Authentication

This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.

In general, the approach for ETP has been similar, in that it does not define any new security protocols. Rather, it relies on the available security mechanisms in its underlying protocols (HTTP, WebSocket, TLS, TCP, etc.). As in WITSML, ETP specifies authentication methods which MUST be implemented by all servers for interoperability, but allows for additional methods (such as client certificates, for example) to be used by agreement between specific parties.

This part of the ETP specification is primarily concerned with the exact mechanism for authenticating the WebSocket upgrade. It is does not attempt to define all of the methods that may be used to acquire credentials, federate identity, etc.

ETP provides two well-known authentication mechanisms:

• JSON Web Tokes (JWT) token-based authentication (MUST be supported)

• Basic authentication

All ETP servers MUST implement JWT. Implementation guidelines for specific domains (such as WITSML v2.0) may provide more strict language that requires one or both of these methods to be supported.

Specific vendors, service companies, and operators MAY also implement any other appropriate security mechanisms (such as SAML tokens), but they are not required by the specification and may lead to interoperability issues.

In all cases, the client SHOULD use the Authorization request header defined by HTTP/1.1. Servers MUST support this method. For browser-based clients, it is not possible to add request headers to the upgrade request. This is because the HTML5 WebSocket API definition does not allow access to the request headers. For this reason, the client MAY provide the information in the query string of the upgrade request. Servers MUST also support this method. If the information is provided in both the request headers and in the query string, the server MUST use the request header.

When provided on the query string, the authentication information MUST be URL-encoded. The query variable is Authorization and the: character is replaced with the equal sign (=). So the following authorization header:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ

Would appear as follows in the query string:

Authorization=Basic%20QWxhZGRpbjpvcGVuIHNlc2FtZQ