Two-factor authentication for corporate web services

In the course of my work I often encounter various kinds of attacks on corporate web services. There were also cases when an attacker managed to gain access to a user account. In order to minimize this risk and secure their services, an idea emerged to introduce a two-factor authentication system, with which it would be possible to secure all corporate web services, that is, infrastructure. The second authentication factor in this case is SMS authorization or e-mail authorization in addition to the existing one on services with password authentication.

Service Description

The service of additional authentication for external access to the company's web services will have to be verified by UID, which is based on the IP address from which it accesses and the user-agent data. If, based on the results of the verification, the UID is not in the trusted database, then authorization is required by entering a one-time password sent to the user's phone number or email account.

After authorization, a UID is added to the authentication system database.

Schematic diagram of the service and the scheme of the components are shown below.
')

Basic system architecture

We defined the following functional requirements for ourselves:

1. Dynamic IP authorization of users of the Company's web services (TCP: 80, 443);
2. Ability to enable authentication for any services, for example, SMTP, IMAP, Jabber, FTP, etc. (with some inconvenience to users);
3. The possibility of access control (filtering) by web services: mail, tracker, etc .;
4. Authorization of new addresses should be done by entering a one-time password received by the user to the previously entered mobile. phone or email;
5. LDAP should be used as the user database;
6. Mobile phones corresponding to the user should be stored in LDAP, the address book of the portal or the local base of the system (implement 1 or more variants);
7. System modularity: (the possibility of replacing individual modules of the system, without serious consequences for the rest of the system: the possibility of replacing the type of authentication, the possibility of replacing the type of firewall or other software);
8. Filtering users by common group (basic group / role giving the user access to the main set of services);
9. The ability to add additional groups (for individual services) and filtering by these groups.
10. Floating shelf life of authorized UIDs, the following parameters should be considered:
    - The duration of the last entry (timeout)
    - Total number of inputs;
11. CAPTCHA + timeout for re-sending after 2-3 sending one-time passwords in a row (for example, 5 minutes), after 5-10 sending - blocking;
12. If the authentication is successful and unsuccessful, the user should receive a message:
    - If successful for a few seconds, the banner "Successful login to the system" is shown, and then the transfer to the desired address
    - If authentication fails, a message is displayed with an error, technical support contacts and a link to re-authenticate
13. Storage of all ip-addresses from which the user received authentication;
14. Storage of all ip-addresses from which the user requested authentication;
15. Restriction on ip of geolocations and TOR;
16. Versatility in the ratio of external / internal addresses;
17. Availability of a number of services only for trusted IP groups (implemented by an optional filter);
18. Ability to limit e-mail servers that can be used to obtain a one-time password;

What do readers think about the proposed method of organizing two-factor authorization? I would be happy to comment and your suggestions.

Also, perhaps, someone can share the experience of implementing a similar system.