Identity and Access Management (IAM) solutions provide business applications with centralized authentication as well as credential management. Competent and thoughtful implementation is the key to success in building centralized authentication systems. Let me describe several vital details of this process.
One of the ways to reduce the information security risks associated with password authentication, as well as to reduce the number of helpdesk requests related to password issues, can be the introduction of the Single Sign-On (SSO).
With SSO, users can get authenticated once and then access protected services without re-entering their credentials. In this case, the first login to the system is often performed using multi-factor authentication (MFA). To implement the Single Sign-On approach, medium and large companies are building centralized authentication systems based on Identity and Access Management solutions.
Preparing this article, I compared leading practices and recommendations for implementing IAM solutions. I selected several topics that are rarely given due attention, but which significantly affect the overall success of building centralized authentication systems.
Important recommendations:
- Conduct an inventory of all information systems in order to evaluate the possibilities of their integration with IAM solutions. Make plans to refine these systems and determine the order of their connection to IAM.
- When implementing Single Sign-On, do not forget about Single Logout.
- Work out different authentication scenarios depending on user types, the device being used, the location of the user, and the type of application.
- If you store user information in different repositories, consider building a single user directory.
- If you are wondering whether to start with IdM or IAM, start with IAM.
Key recommendation:
- Building a centralized authentication system is not the introduction of new software. It is the establishment of a new practice. Speed should not be your priority here. It is advised to focus on choosing the correct sequence and direction of efforts as well as continuous improvement of the system. Do not try to build the system in a snap, do it step by step.
The need to refine your computer systems to support the authentication protocols
When building a centralized authentication system, you will most likely need to refine your computer systems. The most common improvement is to provide support for SAML, OAuth 2.0, and OpenID Connect authentication protocols.
Preparing for the project, you should examine your computer systems and determine whether they support these authentication protocols. If some systems currently do not support the above-mentioned authentication protocols, it is necessary to determine if it is possible to tweak \ remake your computer systems.It often happens that companies do not have qualified employees to remake some elements of their systems, or companies use products that can only be changed by the vendor. Keep in mind that this factor can significantly affect the budget and timing of the project.
After examining your computer systems, determine the order of their connection to IAM. First, it is worth connecting those systems that already support authentication protocols, are ready for integration, and do not need to be tweaked.
Which user sessions to terminate and how to do it
When building a centralized authentication system, companies focus on providing users with access to applications. At the same time, the issue of exiting the application is often given much less attention and sometimes simply forgotten. However, ensuring proper logout can in some cases, be more complicated than designing login functionality.
When logging into applications using the centralized authentication system, the user has separate sessions in each application and a separate session in the centralized authentication system.
The start of the process of exiting applications can occur for several reasons:
- Users can click the “Logout” button in one of the applications or on the centralized authentication system page.
- The administrator can terminate the user's session in the application or in the centralized authentication system.
- Under some conditions, the user's session may expire if the user is inactive or logged in for too long.
In this regard, it is crucial to determine which user sessions to terminate (or not to terminate) when specific events occur. Is it acceptable in your case if any of the listed events occurring in any application triggers the termination of all user sessions? Or is it necessary to terminate sessions selectively depending on the event and application type?
It is also necessary to think about where to send the user after exiting. If, for example, you send a user to the application's homepage, which redirects him to a central authentication system where that very user still has a valid session, he will be returned to the application with a new session created for him. Accordingly, you will see an increase in tech support tickets complaining that logging out does not work. Again, do not focus only on Single Sign-On. You should also think about Single Logout.
Using multi-factor authentication
In authentication systems that utilize Single Sign-On, the user presents his data only once. After successful authentication, the user is provided with pass-through access to all connected applications. It is logical that primary authentication should be performed in secure and reliable ways. This can be achieved with the help of multi-factor authentication.
If it is not possible to use multi-factor authentication for all users, it is necessary to rank the connected applications according to the degree of importance. Then, using just a password for the first login, the user will have access to some unimportant applications.
If it is necessary to access a critical application, the centralized authentication system should request the user to present an additional authentication factor, thereby increasing the level of trust in his session.a fu
It is vital to use multi-factor authentication at an early stage. It is quite possible that you will have to slightly expand the budget and purchase equipment and software that supports several authentication factors.
System operation scenarios
When designing a centralized authentication system, it is necessary to consider the variety of scenarios that may arise during the operation of the system.
Scenarios can often be broken down into the following categories:
· User type (company employee, customer, partner company employee, contractor, etc.).
- User's device (desktop computer, laptop, smartphone, etc.).
- User location (office, home, etc.).
- Type of access (web, VPN, client application, etc.).
- Type of resource or application (corporate application, partner company resources, etc.).
Each individual scenario can include one or several categories.
When designing a centralized authentication system, you need to define the scenarios relevant to your organization and select an authentication method based on the specific scenario. For example, it is often OK to authenticate external users with the help of social networks. For partner companies’ employees, you will probably prefer to set up a trust relationship between yours and their centralized authentication systems. This way the employees of partner companies will be authenticated only in their system but have access to your resources.
In general, it is advised to first design the functional part without tying yourself to any specific software product or vendor. You will be able to select a particular IAM product later.
Building a unified user directory
The Lightweight Directory Access Protocol (LDAP) is an integral part of the user authentication infrastructure. Centralized authentication systems use a directory service as a repository of user information. For the SSO system to work smoothly, it is highly recommended to have a single repository.
It will be challenging to implement unified storage of accounts if you have a large company and users are scattered across different directory services. Still, it is doable. It is advised to create a single directory and let the authentication system work with it. The principle of segregation of duties, when everyone minds their own business, works best here: the directory stores user info and the authentication system certifies identities without worrying about mapping accounts from different directories.
You can use multiple directories when there are significant restrictions on building a single directory. For example, according to some corporate security policies, it is not allowed to store external user records in an internal directory (usually Active Directory). In this case, a separate directory is placed next to Active Directory. IAM systems have options that allow you to use user information located in different directories. But you should not try to combine data from several dozen domains that do not have trust relationships. Let each functional component do its thing.
What to implement first: IdM or IAM?
There is no right or wrong answer to this question. It is generally accepted that one should start with Identity Management (IdM). The logic is simple: you need first to sort out accounts and access rights, and then take on authentication.
Still, I want to suggest starting with IAM solutions and directory services. Why? IdM projects tend to be lengthy and, in addition to tech implementation, may include the automation of many business processes and often their change. Understanding the principles of business processes, discussing their change, changing them - all this takes time. As a result, IdM projects can take years, and you may no longer have time for centralized authentication.
IAM usually takes less time to deploy. It often makes sense to start working on a shorter project and get results soon. In addition, by completing an IAM project, you will be better prepared for an IdM project.
In both projects, the same information systems are used and connected. The differences lie in the fact that in the IAM project - for the purpose of authentication, and in IdM - for managing accounts. These topics are bordering. Already at the stage of a preliminary examination of the information system for the IAM project, the requirements for the IdM project may become clear. So, when starting to discuss IdM in your organization, it is good to have an IAM system already in place.
The implementation of an IAM system is the setting of a new practice
In general, building a centralized authentication system should not be approached as a simple software deployment. In fact, you are not deploying software but creating a new practice within the company. Its success depends not only on proper software and hardware but new competencies of your team and changes in business processes.
Building a centralized authentication system substantially changes the lives of users of your information systems. Yes, ordinary users will hardly need to learn anything new. An exception might be if you use multi-factor authentication with your IAM solution.
Things get much more complicated regarding the owners of information resources. They need to understand that their applications must deal now with authentication in a new centralized system. New applications will need to be designed to integrate with them. Information about the changes should be conveyed to the owners of the systems. They should have all the necessary information to switch to the new practice. For IT infrastructure workers, a new critical service is added. Its failure can paralyze the work of the entire company. This, of course, will require big changes in the work of system operators and their skills and competencies.
In this regard, when setting new practices, do not try to do everything at once. For example, do not try to connect all applications to the system at once. Take just several systems, test them, and see how it goes. There is no need to try to cover all work scenarios at once. Do not expect immediate success. This is a new lifestyle, not a one-time event.
Conclusion
A centralized authentication system based on IAM solutions is a critical system in the IT landscape of any company that uses it. Any failure in its operation can lead to the fact that many business applications will be inaccessible. However, the benefits outweigh the risks. Do not be afraid to implement a centralized authentication system in your company. There are plenty of worthy IAM solutions, and by the current moment, solid implementation experience has already been accumulated.
