LDAP-based unified authentication service Keycloak

foreword

Previously, the author wrote an article “First Experience of OpenLDAP Installation” to try to deploy OpenLDAP with one click using Docker. Among them, the LDAP protocol has also made a certain basic introduction, but there is no in-depth practice on how to use LDAP to provide unified authentication services for various applications. This article intends to integrate LDAP into various third-party systems or services within the team. For example, the private code hosting service Gitlab commonly used within the team, the network disk service Nextcloud, the cache acceleration service Squid, the dedicated OpenVPN service for accessing the internal cluster, the internal team knowledge base service Dokuwiki, the internal code base and container image service Nexus3, etc.

Unified Authentication Service

With the explosive growth of application systems, Unified Authentication Service (UIA) is becoming more and more important. In layman’s terms, unified authentication service means that you can use a set of accounts and passwords to access a series of website applications and APP applications, which saves users the trouble of maintaining a large number of accounts and passwords, and also provides a certain guarantee for the user’s account security. . For example, the unified authentication service can require users to enter multi-factor authentication such as SMS verification code, email verification code or dynamic secondary verification code when logging in, so as to ensure user login security in all aspects. Like in the university, the reason why we can use the student ID and password to access or verify all the school’s website applications and other permissions is because of the unified authentication service.

The unified authentication service is generally associated with authorization control, which can confirm which resources the user has permission to access and which operations can be performed. Of course, each application system can also have its own authorization control system, and it is possible to directly adopt or supplement the authorization control provided by the existing unified authentication service. Common unified authentication solutions are OpenID Connect, OAuth 2.0, SAML2 (Shibboleth), CAS, and more. In fact, these solutions all need to have a way to store user information, of course, we can use a relational database to achieve, we can also use Lightweight Directory Protocol (LDAP) to achieve. As mentioned in the previous article, compared with relational databases, LDAP is faster to query and browse, but LDAP attribute value modification and attributes have certain limitations. Therefore, the actual unified authentication service construction will combine the two and their advantages to complement each other, so as to provide a more comprehensive and reliable authentication service.

In addition to the unified authentication service, there is a single sign-on service (SSO). Compared with unified authentication, after a successful single sign-on login, automatic and non-perceptual authentication can be performed when accessing other website applications that support the same single sign-on, which directly saves the user the trouble of logging in again. Of course, most of the current unified authentication services also integrate the single sign-on service. Therefore, we can think that the complete unified authentication service should have the following points:

Support a set of accounts and passwords to access multiple application systems;
With multi-factor authentication security verification;
Support basic user permission control;
Support single sign-on, automatic non-aware authentication when switching sites.

Unified Authentication Service Practice

Different unified authentication service solutions (protocols) have been introduced in detail in the reference materials given, among which the OpenID Connect solution can meet the above functional requirements better. Wechat, QQ, Baidu, Taobao, etc. used in our daily life all adopt this solution, and we usually call this type of third-party login method “social login”. Of course, the reason why these manufacturers choose OpenID Connect instead of CAS may be mainly because OpenID Connect is a unified authentication service solution based on OAuth 2.0. Although CAS has also begun to have built-in OAuth 2.0 authentication, and is even compatible with SAML2, etc., it will still be limited to B/S scenarios after all. The scenarios for OpenID Connect are not limited to B/S, but also C/S. You must know that with the development of smartphones, mobile clients have become a very large market, and even the daily traffic is much higher than that of desktop browsers.

In order to verify whether LDAP can be used as the basic storage to build a unified authentication service, the well-known open source software Keycloak based on the OpenID Connect protocol developed under the sponsorship of RedHat is selected here. In fact, there are also well-known aperoeo/cas based on the CAS protocol. But what to say, there are two reasons for not choosing it: one is that it is based on the CAS protocol; the other is that its function is a little different from what I want. Although LDAP can also be used as the underlying store, all data is read-only. Personally, I think a unified authentication service solution that can use LDAP as the basic storage should at least give users an option, and whether to choose read-only or writable should be decided by the user. At this point, Keycloak has to do better.

Deployment of Keycloak

Keycloak officially provides compiled Docker images, and we can use docker-compose for one-click deployment. The content of the configuration file is as follows:

 # docker-compose.yml version : ' 3' services : postgres : image : postgres volumes : - ./data:/var/lib/postgresql/data environment : POSTGRES_DB : keycloak POSTGRES_USER : keycloak POSTGRES_PASSWORD : password keycloak : image : quay.io/keycloak/keycloak:legacy environment : DB_VENDOR : POSTGRES DB_ADDR : postgres DB_DATABASE : keycloak DB_USER : keycloak DB_SCHEMA : public DB_PASSWORD : password KEYCLOAK_USER : admin KEYCLOAK_PASSWORD : Pa55w0rd ports : - 8080:8080 depends_on : - postgres

Start the service with the docker-compose up -d command. The legacy tag used here instead of the latest tag is mainly due to the way the Keycloak team is launching and the relevant parameters are being adjusted. The latest tag can be started normally with the docker run command, but docker-compose is a little bit awkward. The code versions of the two tags are actually exactly the same, except that there are some differences in starting the service.

Use of Keycloak

Visit http://127.0.0.1:8080/auth/realms/master/account/#/ to enter the user page, click on the upper right corner to log in. Here directly use the administrator user account and password in the above configuration file.

After successful login, you can see that the user name is already in the upper right corner, and the login button has also become a logout button.

Internationalization settings

Visit http://127.0.0.1:8080/auth/admin/master/console to enter the administrator page and log in automatically.

Switch to the Themes tab, enable internationalization and set the default interface language, then click Save.

Refresh the page to see the set Chinese interface.

connect to LDAP

Switch to the User Federation tab in the left navigation bar and select Add ldap.

Enter the corresponding configuration information as shown below. Here, because it is connected to OpenLDAP, the provider chooses other . In order that the user can modify the LDAP password through Keycloak, the edit mode here can be selected as writable . In addition, after filling in the configuration, you can use the test connection and test verification buttons on the right to test whether the configuration is feasible. As shown in the figure below, a successful verification prompt appears at the top. Click Save to complete the LDAP configuration.

When you refresh the page after saving the LDAP configuration, four new buttons will appear below. Click Sync All Users to sync users to Keycloak.

Switch the left navigation bar to the User tab, which is empty by default. Click View All Users to see users including admin and LDAP.

As shown in the figure below, it proves that Keycloak successfully connects to LDAP.

User Password Policy

Since it is not very convenient to change the password in LDAP itself, it needs to be supported by an additional third-party method. Here, the built-in method of Keycloak is used to modify the password in LDAP. In order to ensure that the user’s modified password has a certain degree of security, we need to set some complex rules for new passwords. Switch the left navigation bar to the Authentication tab, then select the Password Policy tab, use the Add Policy in the upper right corner to add different policy requirements, and click the Save button when finished.

Although we set a policy requirement for the complexity of the new password here, it has not actually taken effect for the users in the system. We need to turn on the authentication password policy in the advanced settings of the LDAP configuration just now. The LDAPv3 password in the figure below can be turned on or not, which has little effect.

In order to verify whether the user password policy is actually in effect, it is necessary to switch to the initial user page. Click the Update button to jump to the update password page. Here, the system may verify the security and require you to enter the password and the secondary verification code (if any) again, just enter it.

The following is an example of the error message returned by setting the simple password 1234. In general, we set the following policies for passwords:

Password length must not be less than 8 digits and not greater than 32 digits
Password must contain both uppercase and lowercase letters
Password must contain numbers
Password must contain at least one special character

OTP verification

As analyzed before, a complete unified authentication service should have multi-factor authentication. The more secure multi-factor authentication is OTP (One Time Password). Keycloak supports OTP authentication. As you can see from the page below, the default OTP policy configuration is to use FreeOTP and Google Authenticator. But if you modify one of the configurations, after saving it will show that only FreeOTP is supported. Oddly enough, FreeOTP, an open source software, doesn’t seem to be updated very much, and its Android client is very old. According to the author’s test, if the OTP strategy supports Google Anthenticator, then the more popular Authy, Microsoft Anthenticator, etc. on the market can support it.

To enable OTP for all users of the system, configure OTP as the default action in the Required Actions tab as shown below. This way, the user will be asked to configure OTP after the first login. (PS: Microsoft’s Office365 also has this default requirement.)

To verify that the OTP is available, go to the User page and click the Set Verify Application button.

Click to jump to the configuration page as follows. Use any of the apps just mentioned to scan the QR code on the page to complete the addition. Then fill in the one-time verification code here according to the secondary verification code displayed on the app, and click Submit. If it jumps normally, the configuration is successful. If the configuration fails, it will stay on this page and a red error message will appear.

LDAP direct integration application

In addition to the above introduction, building an LDAP-based unified authentication service (such as Keycloak) can provide login authentication services for other applications, and can also directly integrate applications with LDAP services. There may be a question here: since LDAP itself can be integrated with applications, why bother to build a unified authentication service based on LDAP? In fact, we need to consider the question “Is it better to expose LDAP on the public network or to expose the unified authentication service to the public network?”. As a directory service, the most fundamental purpose of LDAP is to serve the applications in the internal network, not the applications in the wide area network. With the unified authentication service, LDAP can be well protected in the intranet, and the unified authentication service is used as a web application to interact with other web applications or client applications. This way may appear more elegant and reassuring.

Here, I plan to write a series (dig a hole) on the topic of “LDAP Integration” in the future. (PS: The corresponding link is given in advance, if it can be accessed, it is written.)

References

This article is reprinted from: https://lisz.me/tech/webmaster/ldap-integration.html
This site is for inclusion only, and the copyright belongs to the original author.