2FA for 1C using the OpenID Connect protocol based on Keycloak
Another post about what we are doing. This time I’ll tell you about how we ensured the security of 1C information databases using the Keycloak authentication service through the OpenID Connect protocol and setting up two-factor authentication using an OTP code.
A little about the task and why did you choose Keycloak?
In the 1C migration project to the cloud, our customer had a requirement to provide 2FA when authorizing users in 1C. At the same time, there was no technical opportunity to use the customer’s existing infrastructure as the first factor. We cannot describe the reasons, since they were outside the scope of the project.
It was necessary to propose an implementation that:
uses a centralized storage of information about users (logins, passwords and the second factor);
does not require intervention in the configuration of 1C information bases;
involves minimal user configuration on the database side.
We decided to use an authentication service that interacts with 1C using the OpenID Connect protocol. As an option that best meets the requirements. At ITS, the instructions “Sharing credential access token providers and the 1C:Enterprise platform” mentioned the following providers: Azure AD, AD FS, Google, ESIA and Keycloak.
With all the “wealth of choice”, it was decided to use a solution based on Keycloak as an authentication provider. Firstly, Keycloak is an open source product for implementing single sign-on, secondly, it has the ability to control access, and thirdly, the product is focused on modern applications and services. In addition, Keycloak out of the box offers the ability to use an OTP code as a second factor and supports work with the following applications:
– FreeOTP
– Google Authenticator
– Microsoft Authenticator
How did you set up Keycloak?
To authorize 1C users, a Keycloak server was created. To store service data, we created one Yandex Managed Service for PostgreSQL cluster.
Setting up Keycloak included the following steps:
Installed and started the server in accordance with the Keycloak documentation.
We generated the realm of our project and configured the main parameters: name, event settings, password policies, etc.
We created clients for each 1C infobase and configured: name, type, secret, endpoints, redirects, etc.
Created users for the realm and configured their parameters, such as name, password, 2fa, attributes, etc.
How did you set up 1C?
To configure 1C we performed the following steps:
Installed and launched 1C application servers and 1C web publishing servers according to the documentation.
Created and published 1C information databases in accordance with official documentation.
We configured connection parameters to Keycloak for each 1C infobase in the default.vrd file, specifying the address, identifier and secret of the client created in Keycloak.
We configured the 1C user settings by specifying the authentication type (OpenID Connect) and email address as the user name.
How does the solution work?
After setting up Keycloak and 1C, they received the following authorization process for 1C users:
The user connects with a 1C thin client to the infobase on the web server.
Redirects to Keycloak login page.
Enters username and password. When a user logs in for the first time, they are prompted to change their password.
Redirected to the f2a confirmation page where he has to enter the OTP code received from the OTP application on the mobile device. If a user logs in for the first time, they are prompted to link their new device to the app to generate an OTP code.
Enter the OTP code and click the “Confirm” button
The 1C thin client receives (unnoticed by the user) an access token from Keycloak, which contains information about its identification.
Redirects back to the 1C infobase that he wants to access and passes his access token.
The 1C server verifies the authenticity and validity of the token using the keys and endpoints provided by Keycloak.
The 1C server matches the user name from the access token with the user name in the 1C database and provides the user with access to it in accordance with his rights.
The user can work with the 1C database until his token expires or is revoked.
Benefits of the solution
Security of access to 1C, protection against unauthorized entry using two-factor authentication.
Simplification of user management, centralization of user authorization data (login, password, 2fa) in Keycloak. The 1C administrator will not be able to disable the use of the second factor for any user if he wants.
There is no need to make changes to the configuration of the 1C information base, use external processing, etc.
Compatible with various configurations of 1C information bases. OpenID Connect is a standard functionality of the 1C platform.
Use of different OTP applications at the user's choice.
Peculiarities
Additional resources are required to deploy and maintain the Keycloak servers and PostgreSQL database.
Additional user actions for entering the OTP code each time you log into 1C.
No out-of-the-box support for other types of two-factor authentication other than OTP code (SMS, email, push notifications, etc.)
1C does not support authentication protocols other than OpenID Connect, such as SAML, OAuth, etc.
At the moment (February 2024), the use of this scenario is possible only if client licenses are issued by a 1C cluster (installed on the 1C server). If the client license is installed locally for the user, then the thin client will not be able to connect and will receive from the server the message “Unable to establish a user session.” (More details in the next part)
Bug 70076754 has been logged regarding this: https://bugboard.v8.1c.ru/error/000151413
We hope it gets fixed soon.
Solving the problem with 1C client licenses when authenticating via OpenID Connect
During implementation we encountered a problem: if there are no client licenses in the 1C cluster, an error occurs when trying to authorize via OpenID Connect “Unable to establish user session”. This happens even if the client license is installed locally and a 1C thin client is used to connect.
The customer uses the following license placement scheme:
The 1C server license is located on the licensing server, which is a dedicated server in a cluster with a licensing service. There are no client licenses on the licensing server. 1C client licenses are installed locally on user workstations.
Users connect to infobases published on a web server (ws=“https://server/ib”) using a thin client. When using the “1C:Enterprise Authentication” type, there were no connection problems, and user sessions with a client license were successfully created on the server. An error occurs when trying to authenticate via OpenID Connect “Unable to establish user session”because the server could not find the license.
We contacted 1C support and this problem was registered as an error (https://bugboard.v8.1c.ru/error/000151413), it will probably be fixed in the future. A temporary solution is to use a sufficient number of client licenses on the server and in the 1C cluster.
This situation highlights the importance of having CALs on the server for successful authentication through OpenID Connect and can serve as a lesson for other companies facing similar challenges.
Conclusion
We hope that our experience will be useful to colleagues if they encounter a similar problem in their projects, and that potential clients have learned enough about our abilities and competencies in integrating 2FA systems. If you have any questions or are ready to supplement the material, we will be glad to receive your feedback in the comments.
