The Centreon software is no exception: to gain access, users need to provide credentials so they can be authenticated. That’s how you protect the security and the integrity of your system. But authentication can also become a cumbersome process, so the right balance needs to be found between security and simplicity. In the case of your IT monitoring solution, there are a few elements to consider—from choosing what is required of users to gain access, to managing user accounts—locally or centrally, to managing what exactly each user gets to do and see within the platform. This blog post reviews the basic principles of authentication, present different options to simplify yet ensure secure login, and provide cues on how to integrate your IT monitoring solution to an Identity Provider solution to enable single sign on (SSO).
User authentication: the basics
You probably already manage user access to your IT monitoring solution. Just like for any other software, this entails users entering a valid username and password. But with the need for improved security and simplicity, user authentication now involves other possibilities, such as a fingerprint or some other kind of biometric recognition. And often, authentication will require coupling multiple credentials, this is referred to as multi-factor authentication or MFA.
Then, the proper rights of access must be enforced for the user who just got authenticated. This requires the application to associate that person with a user profile. This part of the process is called authorization. This is how you apply appropriate access rights or ACL (Access Control List) to a given user. ACL defines each user’s authorized actions, the menus available in the application, etc.
So now how does this apply to your IT monitoring solution and various usage scenarios?
User definition: local or centralized?
In a test environment, defining user accounts locally makes a lot of sense, because it’s easier to create and manage user profiles. But for a solution in production, the best practice for organizations is to centralize such profiles in a directory. This greatly facilitates making changes such as adding and removing users as employees come and go or changing user rights as their needs change.
Centralizing access authorizations
In today’s application-rich work environment, it makes a lot of sense to centralize application access authorizations, to simplify the process from an administrator standpoint. Enters the identity provider (IdP), a solution that stores user profiles and the various applications they can have access to, acting a little like a security guard in a building lobby, who lets in only registered guests, except it’s to applications, not floors in this case. This process is called delegation of authentication. Examples of such IdPs are LDAP directories, such as Microsoft Active Directory or their open source counterparts with OpenLDAP or LemonLDAP, etc.. IdP often combines with single sign on (SSO), which many organizations have also implemented to make life easier for users. Microsoft Azure AD or Okta provide this type of authentication, among others.
Single sign on (SSO) and how it interacts with the IdPs
SSO is the ability to authenticate once and be able to switch from one application to the next without having to re-authenticate. When a user wants to access a new application, the application will contact the identity provider to retrieve the user’s parameters (last name, first name, email address, etc.), and because the user is already authenticated, the ID provider will pass along the credential to the next application, it’s all transparent for the user who does not have to input any information.
Today, two major protocols are employed to achieve identity delegation and SSO: SAMLv2 and OpenID Connect (OIDC). From these two protocols, variations have been developed to meet specific needs. An example of such a variation are the buttons “Sign in with Apple” or “Sign in with Google” which you often see when attempting to log in to an app.
Integrating the IT monitoring platform to the IdP and SSO provider
Centreon supports the LDAP protocol for user authentication and authorization. For SSO, Centreon supports either web-based SSO or direct integration modes with OIDC. For web-based SSO, authentication happens between the web server (Apache) and the identity provider. In this case, you can use SAMLv2 or OIDC with Apache add-ons. In a direct integration configuration within Centreon, the OIDC protocol is used for users that are already registered. We have validated the authentication with Okta, Microsoft Azure, or even Keycloak. For our next version, we are working on integrating authorizations via the OIDC protocol within Centreon to further simplify user access management for administrators with the ability to import new users and apply Centreon profiles (ACL).
Granting specific access rights to Centreon via IdP and SSO
In closing, it’s important to remember that IdPs let you add information to the user profile with the requesting application. For example, you can create groups to which you can subscribe users. It’s through such groupings that the application can associate a given user profile with their access rights, making it easy for you to make changes to who gets access to what.
Any questions on that topic? Follow us on The Watch for more discussions like this one or contact us with your question.
To learn more, watch this video with Laurent Pinsivy, Product Manager.
Share
