前言

soanr 是一個代碼質量管理系統(tǒng)，代碼是開源的。在公司統(tǒng)一認證平臺還沒出來時，sonar 已接入 ldap 提供系統(tǒng)登錄認證功能，現在使用 sonar-auth-oidc 插件以 OIDC 協(xié)議接入集中認證平臺時，發(fā)現用戶的賬戶是互斥的（如果現有用戶之前采用 ldap 登錄，使用 oidc 登錄后會創(chuàng)建一個新的用戶，沒法關聯之前的賬戶），即使用戶的所有信息一致也是如此。本文旨在分析具體原因以及尋求一種可實施的解決方案

相關鏈接：

• soanrqube ：https://github.com/SonarSource/sonarqube
• soanr-auth-oidc : https://github.com/vaulttec/sonar-auth-oidc

sonar 插件實現分析

以 sonar-auth-oidc 為例，實現一個 soanr 的插件，需要如下步驟：

1、實現對應的插件接口

soanr 將可以擴展的通用的功能抽象定義放到了 sonar-plugin-api 模塊，實現插件首先需要依賴這個模塊，然后需要實現什么功能，找到對應的接口定義，以 sonar-auth-oidc 為例，需要實現 OAuth2IdentityProvider 接口。

@ServerSide
public class OidcIdentityProvider implements OAuth2IdentityProvider {
  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;
  }
  //省略非關鍵邏輯
  @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、實現 plugin 接口，聲明擴展類

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、使用插件打包工具，打包插件

<plugin>
 <groupId>org.sonarsource.sonar-packaging-maven-plugin</groupId>
 <artifactId>sonar-packaging-maven-plugin</artifactId>
 <version>1.18.0.372</version>
 <extensions>true</extensions>
 <configuration>
  <pluginClass>org.vaulttec.sonarqube.auth.oidc.AuthOidcPlugin</pluginClass>
 </configuration>
</plugin>

插件工作原理淺析

插件完成后，最終會打成 jar 包，在應用市場安裝插件，相當于下載了一個 jar 放到了 soanrqube 安裝目錄的 ./extensions/plugins 路徑下。上面的打包工具會給 jar 包清單 META-INF/MANIFEST.MF 里加上

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

soanrqube 啟動時，插件掃描器會掃到這個 jar ，解析拿到 plugin-class 并加載插件。

sonar-auth-oidc 實現邏輯分析

從sonar 插件實現分析了解到，sonar-auth-oidc 實現 Oauth 認證的關鍵邏輯在 OidcIdentityProvider 類里，關鍵代碼如下：

init 方法

集成 oidc 插件后，訪問 soanr 會顯示如下登錄入口

該登錄按鈕的鏈接為：http://172.26.202.128:9000/sessions/init/oidc?return_to=%2F ，點擊這個鏈接，就會觸發(fā)插件里 init 方法，init 方法里拼裝了 oidc 授權服務器的接口地址并重定向到這地址，等待用戶授權

callback 方法

用戶在授權服務器授權頁面授權完成后，授權服務器會回調 soanr 服務，最終觸發(fā) callback 函數。在 callback 函數里，首先從 request 里拿到了 authorizationCode ，然后使用 code 請求 oidc 授權服務器，拿到了 UserInfo，使用 UserInfo 里的信息，組裝了 soanr 內置的認證類 UserIdentity 。然后調用了 authenticate 完成認證，如果認證成功，沒有異常，則重定向到了登錄成功的頁面?？吹竭@里，最關鍵的地方是 UserIdentity ，前面一大堆邏輯，最終就為了組裝出這個實體，這個類定義如下：

sonar-auth-oidc 插件里有用的信息，就這些了，關鍵的是 UserIdentity ，接下來需要從 sonarqube 里找到 CallBackContext 的實現類，看 authenticate() 方法里是怎么處理 UserIdentity 的。

soanrqube 的 auth 模塊分析

soanr 的web 登錄認證功能在 sonar-webserver-auth 模塊，上文在 oidc 插件里出現的 InitContext 、 CallBackContxt 均在 OAuth2ContextFactory 類里被初始化，關鍵邏輯如下：

authenticate 過程

• 1、執(zhí)行用戶注冊邏輯(內部控制了是注冊還是更新)
• 2、生成登錄用的 jwt 串
• 3、設置本地用戶登錄的 session

register 過程

1、通過 externalId 和 IdentityProvider 查詢用戶，如果為空，則通過 externalLogin 和 IdentityProvider 查詢用戶

2、如果 user 不存在或者已禁用，則創(chuàng)建一個新的用戶，否則注冊一個已存在的用戶(更新用戶信息)

關鍵點開始凸顯出來了，關鍵邏輯在這里，通過 externalId 和 IdentityProvider、externalLogin 等條件沒有查詢到用戶信息，所以才創(chuàng)建了新的用戶，接下來看下數據庫里 User 存儲了哪些信息。

User 表數據分析

本地 sonar 嘗試對接過 ldap 、gitlab 、oidc ，所以一個賬戶有三條用戶數據，其中 ldap 賬戶的 identityProvider 被標記為 sonarqube 了，而使用 OIDC 登錄被標記為 oidc（插件的 key），所以才導致通過 externalId 和 IdentityProvider、externalLogin 等信息都查詢不到用戶信息

解決方案

經過分析后，知道了 oidc 和 ldap 賬戶互斥的根本原因為，不同 identityProvider 的用戶會被加上 provider_key 區(qū)分，導致同一個用戶，即使用戶信息一樣，從不同的 identityProvider 認證也會生成不同的用戶。所以，可以從如下兩個方案出發(fā)，解決問題

方案一：重寫插件，將 identityProvider 標識和 LDAP 的同步。

• 優(yōu)點：兼容 LDAP 和 identityProvider 賬戶，可以設計下兼容所以的 identityProvider
• 缺點：實施比較困難，需要自己維護插件或者尋求官方倉庫合并 pr

方案二：修改數據庫中存量 LDAP 用戶的 identityProvider 的標識為 oidc。

• 優(yōu)點：改動較簡單
• 缺點：LDAP 和 OIDC 不兼容，集成 OIDC 后，只能被動的關閉 LDAP，而原 LDAP 的輸入框和本地用戶密碼框是一起的，沒法移除，對用戶使用習慣會有影響

以上就是原理分析SonarQube中IdentityProvider賬戶互斥現象的詳細內容，更多關于分析SonarQube中IdentityProvider賬戶互斥的資料請關注腳本之家其它相關文章！

最新評論