Remark is an industry-specific digital integrator. Since 2007 we have been helping companies to be as efficient as possible in the digital environment by automating the processes of marketing, sales and internal interaction between employees. Our main expertise is in real estate, but years of experience and competencies allow us to work with companies in all industries.
Email us
Call us
We developed a module for non-standard Bitrix24 authorization: it functions depending on the
employee’s location.
employee’s location.
Secured login to Bitrix24 not using a code on your phone
The client
We were approached by foreign partners with a proposal to develop for their client a module for convenient and secure authorization in Bitrix24. Some of the company’s employees work in the office, some work remotely: from home or public places.
The task
The standard functionality of the Bitrix24 cloud solution provides for OTP authorization for the security of company data. The user opens the portal and a one-time code is sent to his phone.
Our client was using the on-premise version of Bitrix24. The task was to develop a module that would allow employees:
Our client was using the on-premise version of Bitrix24. The task was to develop a module that would allow employees:
- authorize in Bitrix24 without additional authentication such as requesting a code on the phone, provided they work from the office.
- use two-factor authentication, such as logging in to Bitrix24 by requesting a code on the phone, in case of working from a cafe or hotel.
The solution
In the office, employees worked on a secure local area network. The client’s task was quite specific: in the office network — one set of rules, outside the office network — another. Therefore, the first thing we suggested and eventually settled on was IP-based verification.
- Sergey LevinChief Technical OfficerThe most convenient solution was to separate the logic of authorization by IP-addresses for the system. In other words, to make office IP addresses allowed or trusted for the system, and not to apply two-factor authorization for them.
The company could update the list of authorized IP addresses on its own if necessary.
To implement the required functionality, we used the Bitrix24 core API and packaged the solution into a module for the on-premise version.
The module enables or disables OTP authorization for a particular user depending on their current IP address. By default, there is no OTP for each user. Further, depending on the situation that occurs when a user is authorized, the module logic is enabled. The logic itself is based on subscription to events that the module receives via API from Bitrix24.
To implement the required functionality, we used the Bitrix24 core API and packaged the solution into a module for the on-premise version.
The module enables or disables OTP authorization for a particular user depending on their current IP address. By default, there is no OTP for each user. Further, depending on the situation that occurs when a user is authorized, the module logic is enabled. The logic itself is based on subscription to events that the module receives via API from Bitrix24.
OnBeforeUserLogin
Triggers immediately before authorizing the user in the system. In this event listener we:
- 1Get the user’s IP address and compare it with the list of trusted addresses.
- 2If the address is trusted, the module stops working and the user remains with disabled OTP-authorization functionality.
- 3Otherwise, it enables OTP for this user, if he belongs to the group of users covered by the module logic.
OnAfterUserLogin
is triggered after user authorization, and is used to disable OTP for this user, as this is the default state for all users of the system belonging to the corresponding group.
The module settings interface contains a field for filling in the allowed IP addresses — whitelist. And a field for selecting the user group to which the module logic should be applied. We did not make this field multiple, as it would be redundant considering the flexible in-house system of Bitrix24 user group management. But whitelist is a classic IP list separated by semicolons. Also, for ease of use, the IP address of the current device is displayed in the module interface.
The module settings interface contains a field for filling in the allowed IP addresses — whitelist. And a field for selecting the user group to which the module logic should be applied. We did not make this field multiple, as it would be redundant considering the flexible in-house system of Bitrix24 user group management. But whitelist is a classic IP list separated by semicolons. Also, for ease of use, the IP address of the current device is displayed in the module interface.
Since the solution is implemented as a Bitrix24 module, and is made entirely according to Bitrix methodology, we did not have to solve the problem of access to module settings management: there is no risk that any of the employees or intruders will be able to disable OTP settings. This screen can be accessed only by users who have access to the administrative panel and whose access rights allow them to manage modules.
The development was done on our test server, on one of our on-premise Bitrix24 portals. Upon completion, we provided instructions on installing and configuring the module for the client’s DevOps specialists.
The development was done on our test server, on one of our on-premise Bitrix24 portals. Upon completion, we provided instructions on installing and configuring the module for the client’s DevOps specialists.
The problem and the solution
After installing the module on the client’s test portal according to the instructions, the client asked us for help in diagnosing the problem: any authorization attempt passed without using OTP, even for IP addresses that were not included in the whitelist.
We connected to the portal and found out that all requests to the client’s portal came from the IP address of the office router. The problem was related to the router settings, which worked on the principle of an non-transparent proxy server, i.e. it did not pass the real IP address of the user’s device to the PHP interpreter. This made it impossible to use the module with the current settings. We advised the client on how to fix the problem.
We connected to the portal and found out that all requests to the client’s portal came from the IP address of the office router. The problem was related to the router settings, which worked on the principle of an non-transparent proxy server, i.e. it did not pass the real IP address of the user’s device to the PHP interpreter. This made it impossible to use the module with the current settings. We advised the client on how to fix the problem.
The result
The client organized convenient access to Bitrix24, which meets security requirements and includes two-factor authentication only when accessing the network outside the office. This saves employees' efforts and keeps company data safe.
