Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "case analysis of mutual exclusion of IdentityProvider accounts in SonarQube". The editor shows you the operation process through actual cases, and the operation method is simple, fast and practical. I hope that this article "case analysis of mutual exclusion of IdentityProvider accounts in SonarQube" can help you solve the problem.

Preface

Soanr is a code quality management system and the code is open source. Before the company's unified authentication platform came out, sonar has been connected to ldap to provide system login authentication. Now, when using the sonar-auth-oidc plug-in to access the centralized authentication platform with OIDC protocol, it is found that users' accounts are mutually exclusive (if existing users log in with ldap before, a new user will be created after logging in using oidc, and it is impossible to associate with the previous account), even if all the information of the user is consistent.

Implementation Analysis of sonar plug-in

Take sonar-auth-oidc as an example. To implement a plug-in for soanr, you need to take the following steps:

1. Implement the corresponding plug-in interface

Soanr puts the extensible general function abstract definition into the sonar-plugin-api module, the implementation plug-in first needs to rely on this module, and then what function needs to be realized, find the corresponding interface definition, take sonar-auth-oidc as an example, need to implement the OAuth3IdentityProvider interface.

@ ServerSidepublic class OidcIdentityProvider implements OAuth3IdentityProvider {private static final Logger LOGGER = Loggers.get (OidcIdentityProvider.class); public static final String KEY = "oidc"; private final OidcConfiguration config; private final OidcClient client; private final UserIdentityFactory userIdentityFactory; public OidcIdentityProvider (OidcConfiguration config, OidcClient client, UserIdentityFactory userIdentityFactory) {this.config = config; this.client = client; this.userIdentityFactory = userIdentityFactory;} / / omit non-critical logic @ Override public void init (InitContext context) {LOGGER.trace ("Starting authentication workflow") If (! isEnabled ()) {throw new IllegalStateException ("OpenID Connect authentication is disabled");} String state = context.generateCsrfState (); AuthenticationRequest authenticationRequest = client.getAuthenticationRequest (context.getCallbackUrl (), state); LOGGER.trace ("Redirecting to authentication endpoint"); context.redirectTo (authenticationRequest.toURI (). ToString ());} @ Override public void callback (CallbackContext context) {LOGGER.trace ("Handling authentication response"); context.verifyCsrfState () AuthorizationCode authorizationCode = client.getAuthorizationCode (context.getRequest ()); UserInfo userInfo = client.getUserInfo (authorizationCode, context.getCallbackUrl ()); UserIdentity userIdentity = userIdentityFactory.create (userInfo); LOGGER.debug ("Authenticating user'{} 'with groups {}", userIdentity.getProviderLogin (), userIdentity.getGroups ()); context.authenticate (userIdentity); LOGGER.trace ("Redirecting to requested page"); context.redirectToRequestedPage () 2. Implement the plugin interface and declare the extension class public class AuthOidcPlugin implements Plugin {@ Override public void define (Context context) {context.addExtensions (OidcConfiguration.class, OidcClient.class, OidcIdentityProvider.class, UserIdentityFactory.class); context.addExtensions (OidcConfiguration.definitions ()) 3. Use the plug-in packaging tool to package the plug-in org.sonarsource.sonar-packaging-maven-plugin sonar-packaging-maven-plugin 1.18.0.372 true org.vaulttec.sonarqube.auth.oidc.AuthOidcPlugin plug-in working principle

After the plug-in is completed, it will eventually be packed into a jar package to install the plug-in in the application market, which is equivalent to downloading a jar and putting it in the. / extensions/plugins path of the soanrqube installation directory. The packaging tool above will add to the jar package list META-INF/MANIFEST.MF

Plugin-Class: org.vaulttec.sonarqube.auth.oidc.AuthOidcPlugin .

When soanrqube starts, the plug-in scanner scans to the jar, parses to get the plugin-class, and loads the plug-in.

Logic Analysis of sonar-auth-oidc implementation

According to the analysis of sonar plug-in implementation, the key logic for sonar-auth-oidc to implement Oauth authentication is in the OidcIdentityProvider class, and the key code is as follows:

Init method

After integrating the oidc plug-in, accessing the soanr will display the following login entry

The link to the login button is: http://172.26.202.128:9000/sessions/init/oidc?return_to=%2F. Clicking this link will trigger the init method in the plug-in. The init method assembles the interface address of the oidc authorization server and redirects it to this address, waiting for user authorization.

Callback method

After the authorization is completed on the authorization page of the authorization server, the authorization server will call back the soanr service and finally trigger the callback function. In the callback function, you first get the authorizationCode from request, then use code to request the oidc authorization server, get the UserInfo, use the information in UserInfo, and assemble soanr's built-in authentication class UserIdentity. Then the authenticate is called to complete the authentication, and if the authentication is successful and there is no exception, it is redirected to the page where the login was successful. The most important thing to see here is UserIdentity, which has a lot of logic in front of it, and finally to assemble this entity, which is defined as follows:

That's all the useful information in the sonar-auth-oidc plug-in. The key is UserIdentity. Next, you need to find the implementation class of CallBackContext in sonarqube to see how UserIdentity is handled in the authenticate () method.

Auth Module Analysis of soanrqube

Soanr's web login authentication feature is in the sonar-webserver-auth module. InitContext and CallBackContxt, which appear in the oidc plug-in above, are initialized in the OAuth3ContextFactory class. The key logic is as follows:

Authenticate process

1. Execute the user registration logic (internally control whether to register or update)

2. Generate jwt string for login

3. Set the session for local users to log in

Register process

1. Query users through externalId and IdentityProvider. If empty, query users through externalLogin and IdentityProvider.

2. If user does not exist or is disabled, create a new user, otherwise register an existing user (update user information)

The key point begins to be highlighted. The key logic is here. User information is not queried through externalId, IdentityProvider, externalLogin and other conditions, so new users are created. Next, let's take a look at what information is stored in User in the database.

Data analysis of User table

The local sonar tries to connect with ldap, gitlab and oidc, so an account has three pieces of user data, of which the identityProvider of the ldap account is marked as sonarqube, and the login using OIDC is marked as oidc (plug-in key), so the user information cannot be queried through externalId, IdentityProvider, externalLogin and other information.

Solution

After analysis, we know that the root cause of mutual exclusion between oidc and ldap accounts is that different identityProvider users will be distinguished by provider_key, resulting in the same user, even if the user information is the same, different identityProvider authentication will generate different users. Therefore, we can solve the problem from the following two solutions

Solution 1: rewrite the plug-in to synchronize the identityProvider logo with the LDAP.

Advantages: compatible with LDAP and identityProvider accounts, can be designed to be compatible with all identityProvider

Disadvantages: it is difficult to implement, you need to maintain your own plug-ins or seek an official warehouse to merge pr

Scheme 2: modify the identityProvider identification of the stock LDAP users in the database to oidc.

Advantages: easy to change

Disadvantages: LDAP and OIDC are not compatible. After integrating OIDC, LDAP can only be turned off passively, while the input box of the original LDAP and the local user password box are together and cannot be removed, which will have an impact on users' habits.

This is the end of the "case Analysis of Mutual exclusion of IdentityProvider accounts in SonarQube". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.