Security

Table of Contents

• Supported TLS Versions
• Server Certificate
• Authentication
• Access Control

The Xentara Web Service only supports encrypted communication using HTTPs. Plain-text HTTP is not supported for security reasons.

Supported TLS Versions

The Xentara Web service only supports TLS versions 1.2 and 1.3. It does not support TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0, or SSL 1.0, as these versions are no longer considered secure. (See also RFC 8996, RFC 7568, and RFC 6176.)

Server Certificate

See also

TLS (Transport Layer Security) in the Xentara user manual

When accepting TLS connections from remote clients, The Xentara web service needs to present a valid certificate to the client. Normally, the Xentara web service uses the global Xentara server certificate. You can specify an alternate certificate path in the configuration of the individual server elements, however.

Authentication

See also

Authentication in the Xentara user manual

The Xentara web service requires authentication for all HTTP requests. The Xentara web service supports two HTTP authentication schemes:

• OAuth 2.0 authorization using the “Bearer” HTTP authentication scheme, as described in RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage, and
• Username/password authentication using the “Basic” HTTP authentication scheme, as described in RFC 7617 — The 'Basic' HTTP Authentication Scheme.

The authentication parameters, like allowed token issuers and usernames and passwords, are taken from the global Xentara authentication configuration described under Authentication in the Xentara user manual.

Access Control

See also

ACLs (Access Control Lists) in the Xentara user manual

The Xentara web service uses the built-in Xentara access control list (ACL) functionality to determine whether a client is allowed to connect to the web service, and whether a client is allowed to read and/or write a specific data point.

To control whether a client is allowed to connect, the Xentara web service defines a special entitlement named WebService.connect.

Access control is checked as followed:

• To determine whether a client is allowed to connect, the entitlement WebService.connect is checked against the ACL of the web service server element the client is attempting to connect to.
• To determine whether a client is allowed to read a specific data point, whether through a regular enpoint, or through a [batch read endpoint]()Batch Reading, the built-in entitlement read is checked against the ACL of the data point the client is attemting to read.
• To determine whether a client is allowed to write a specific data point, whether through a regular enpoint, or through a [batch write endpoint]()Batch Writing, the built-in entitlement write is checked against the ACL of the data point the client is attemting to read.

The custom entitlement WebService.connect is included in the “allow” list of the default ACL, as described under Inheritance for the global ACL in the Xentara user manual. This essentially means that connecting to the Xentara web service is allowed for everyone unless it has been explicitly denied in an ACL.

Attention

Prior to version 2.0, the Xentara web service used its own custom authentication configuration instead of the built-in Xentara configuration. To maintain backward compatibility with existing systems, ACLs are not checked if the configuration of the server element in the Xentara model file contains a legacy authentication configuration. It is therefore strongly recommended to update old configurations to use the built-in Xentara authentication mechanism.