Using a secure channel to interact with the webserver

Safety while using Internet services

Authentication

In general, the procedure of a client accessing an Internet service is as follows:

Fig. Internet service connections

There are three different types of authentication:

  • On a proxy server‑, this authentication is not directly related to the use of a web server, but you should remember about it if you need to use an Internet service from a network behind a proxy server.
  • In this case, the following types of authentication can be used on the web server‑:
    • Anonymous authentication ‑ in this case, all requests coming from the webserver are performed under a special user, which impersonates the "anonymous" connection.

      In this case, the authentication in 1C:Enterprise is performed using the username and password passed in the HTTP request.

    • Basic authentication ‑ in this case, the client of the Internet service passes for authentication to the web server the username and password in an HTTP request that is generated when accessing the webserver.

      In order to successfully perform this type of authentication, the username and password used to access 1C:Enterprise must also be used to access the webserver. If a user, whose parameters are passed in an HTTP request, cannot access the webserver, it means that he/she will not be able to use the Internet service.

    • OS authentication ‑ in this case, the webserver determines on which behalf of the OS user the Internet service performs the access to 1C:Enterprise and further this particular data is used.

      In this case, the webserver determines the OS user who is trying to access the web server, and then transfers to 1C:Enterprise both the parameters of the OS user and the data passed in the HTTP request to the Internet service. If the HTTP request contains the username and password, then it is they who are used for authentication, and the OS user data are not used. If the username and password in the HTTP request are not specified ‑, the data of a specific OS user is used.

      For a thin client connecting to the Infobase via HTTP protocol (via a webserver), and for a web client, the OS authentication operation is based on the possibility of impersonalizing a web browser user or a thin client user in a web server thread that executes HTTP requests. The impersonation of users by a web server depends on the type and setting of the web browser used, the type and setting of the web server, the settings of individual user rights, domain security policies, etc. Impersonation is not always possible.

      The corresponding settings are the subject of the administration of the network environment and are beyond the scope of the 1C:Enterprise documentation.

  • 1C:Enterprise authentication. To perform this authentication, the webserver extension uses the username and password that are transmitted by the webserver (when using Basic authentication or OS authentication on the webserver). If you use anonymous authentication on a web server, 1C:Enterprise will request Basic authentication from the caller. 1C:Enterprise expects that the username and password of the user will be passed in UTF-8 encoding.

    If the Internet service is accessed from the Microsoft Internet Explorer web browser, it is not recommended to use non-Latin characters in the username and password.

When interacting with a web server, it is possible to organize operations via a secure channel.

When using the file mode of the Infobase, the users on whose behalf access is performed must have access to the execution of the files of the required version of 1C:Enterprise and the rights to read and modify data in the Infobase directory.

Operations over a secure channel

When a client interacts with an Internet services server, data can be exchanged over a secure channel. Secure communication channels prevent unauthorized viewing and alteration of data. The secure channel is TLS-based (version 1.2). TLS connections support cryptographic algorithms that comply with GOST R 34.10-94, R 34.10-2001, R 34.10-2012, R 34.11-94, R 34.11-2012, and 28147-89. The obsolete SSL 3.0 protocol can be enabled using the command line to start a client connection.

The TLS (Transport Layer Security) ‑ protocol is used to provide secure communication between a client and a server. TLS is based on:

  • Mutual authentication of the client and the server, so that both the client and the server are certain of each other's identities
  • Digital signatures to ensure data integrity (protecting data from unauthorized alteration)
  • Encryption to ensure the confidentiality of data (protecting data from unauthorized viewing)

TLS protocol supports various encryption options, digital signatures, certificates, etc., in order to provide a secure channel with the required robustness.

TLS protocol uses a TLS session to establish a secure connection between the a and a server. The session is established by exchanging a sequence of messages between a client and a server. When establishing a session, the following actions can be performed:

  • Determining cryptography algorithms that will be used to encrypt and digitally sign the transmitted data
  • Setting the session key
  • Performing server authentication on the client-side
  • Performing client authentication on the server-side

To authenticate the client on the server-side and server on the client-side, TLS uses certificates. A certificate is a document that describes a set of parameters of the party being authenticated. 

For example, the certificate may contain the username or the name of the server web site. The certificate also contains a digital signature, which is used to verify its validity. Chains of certificates are used to prevent the possibility of uncontrolled issuance of certificates. The beginning of the chain of certificates is the Certificate Authority‑ an organization issuing certificates. If a particular user needs a certificate, he/she sends a request to the Certificate Authority to issue a certificate. Certificate Authority issues a certificate that is signed with its own private key. The user to whom the certificate is issued may, in turn, act as a Certificate Authority for other users. Thus, a chain of certificates is formed, the root of which is the Root Certificate Authority, which is, as a rule, a well-known organization. For a client to accept this certificate, it must be on the list of the certificates that this client trusts. The list can include both this certificate and any other certificates from the certificate chain of this certificate. As a rule, this is a certificate from the Root Certificate Authority. 

Please remember that 1C:Enterprise operates correctly with certificates only if the certificate fields contain data in US ASCII or characters encoded with Punycode. Certificate fields must not contain data in Unicode.

One of the most common uses of the TLS protocol is its use for sending HTTP requests (the HTTPS protocol). In this case, the URL is the addressing scheme for such ‑HTTPS resources, and the default port is ‑443.

The client part of the Web services engine automatically, using the URL scheme (HTTPS) of the location of the Web service, determines that the interaction with the Web service should be performed over a secure communication channel. The client also requires that a valid certificate be linked to the server issued by a Certificate Authority known to the client.

A server certificate is valid if its digital signature matches the content of the certificate, its validity date is not expired, and the website, for which the certificate was issued, corresponds to the server website. If the certificate is not valid, for example, the certificate website does not match the server website, then the client will not be able to communicate via TLS with the Web services of this website.

In order to enable the operation via TLS protocol, you need to:

  • Obtain a server certificate for the website, for which you plan to use TLS. The certificate is issued by a Certificate Authority and is linked to this website.
  • TLS support must be enabled for the webserver.
  • In order for an application using a Web service to use a secure connection, you must explicitly specify this when connecting to the Web service. To do this, when creating WS Determinations and WS Proxy objects, you must specify the SecureConnection parameter. When using a secure connection, you must specify the SecureConnectionOpenSSL object as the value of this parameter.

Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.