Image
How we made a portable service to integrate products with Active Directory
Active Directory is one of the most popular directory services and is used by most of our customers. So the need to integrate with it is apparent on almost every project. In order for the teams to avoid the need to solve this problem again every time, our developers have created a service that can now be integrated into other products in a ready-made form. Sharing the experience.
Image
Any product has users, and their information must be managed somehow - accounts must be created, passwords saved, users added to groups, etc. User data is stored in Active Directory, and developers of new products therefore need to build connections with this service, register all the necessary processes, and take care of security.
We have now automated this part of our work within a separate AReS microservice, from Account Registration Service. It can create new users in AD, send them emails with registration information, and remind them to create a password. This is a complete component, and it can be copied to almost any product.
The architecture of the process
When a user logs in, their data is sent to RabbitMQ, where it is picked up by AReS. The package contains all the information needed to create an account:
- user name
- e-mail address, groups of which the user is a part
- mails they receive
AReS passes this data to Active Directory, or rather to the Active Directory Management Service microservice. The information then is stored in the database, after which the user has to create a password.
One of the requirements for AReS was not to send users’ passwords, even temporary ones. So instead, the service sends an email with a link that leads to a page for creating a password. The logic is set up so that the user has two weeks to come up with an access code. During this time, he will receive a reminder twice – first one week and then thirteen days after the registration attempt. If a password still has not been created after this period, the AD account is marked as inactive.
The MailService module is responsible for sending emails. It also stores email layouts, so that all notifications come in a neat form, designed according to the corporate style.
As a result, we have a complete process: the user sends their data, it is stored in Active Directory, and access to the systems is protected by a password that cannot be intercepted.
Advantages
Most importantly, AReS is ready for use in any product. As we said at the beginning, this was the original goal – to relieve the teams from having to re-write the same module. The design, content and frequency of emails, and the business logic of the participating services can be easily changed. This means that there is less routine work, and there is less risk that an error will get into the code which will have to be caught later on, leaving more time for more interesting tasks.
The second important advantage is that AReS receives data through Rabbit, so there is no need to build a direct means of communication between it and the product that we connect to AD. This architecture allows you to build an event model and quickly design a variety of complex scripts: automatic creation of user groups, policy deployment, and access control to information resources.
And to comment once again password security – with this approach, only users know them.
How we plan to develop the module
AReS is already running in combat mode within one of our products, and we will soon connect it to another system. Next, we plan to integrate it with our Notification Center so that it provides mailing instead of MailService.
The Notification center is our special product for managing communications for all corporate services. It includes the control of all notifications and mailings, the method of their delivery and other subtleties that are built into the logic of each individual system. So, if a company uses the Notification Center, there is no need for an additional module in the form of MailService.
We also want to expand the capabilities for working with AD itself. It allows you to manage not only user accounts, but also their workstations. You can configure the option for groups of employees to use only specific computers – for example, no one can log in to the CEO's laptop. The same applies to cash registers, terminals, and other devices where you need to log in via AD. Our module will help you embed the rules for working with them in the product logic, so that administrators do not have to configure it separately.