1. 程式人生 > 程式設計 >Flowable自定義許可權

Flowable自定義許可權

Flowable預設提供了一套自己的許可權管理介面(IDM),但是從Flowable 6開始,IDM的元件被獨立出來,分為幾個不同的模組:flowable-idm-api,flowable-idm-engine,flowable-idm-spring 和 flowable-idm-engine-configurator。

官方之所以將IDM拆分出來,一個是因為IDM模組並不是核心的模組,另外在很多使用Flowable的場景中,許可權管理並不需要,或者大多使用許可權的時候需要我們使用自己的許可權模組,而不是預設的實現。

預設實現

Flowable預設提供了兩種方式可以處理許可權相關:

1 通過IdentityService,這個服務主要用來管理使用者和組,不能操作具體的許可權。是簡單版

processEngine.getIdentityService();
複製程式碼

2 通過IdmIdentityService,可以使用者和組,同時可以處理具體的許可權(Privilege),在IdentityService之上做了增強,但兩者是不同的介面。

IdmEngineConfigurator idmEngineConfigurator = new IdmEngineConfigurator();
cfg.setIdmEngineConfigurator(idmEngineConfigurator);
// 會初始化processEngine,同時初始化配置在裡面的Configurator,如IdmEngineConfigurator
ProcessEngine processEngine = cfg.buildProcessEngine();
IdmIdentityService idmIdentityService = idmEngineConfigurator.getIdmEngineConfiguration().getIdmIdentityService();
複製程式碼

兩個服務用到的是Flowable中相同的表:

  • ACT_ID_USER 儲存的使用者,呼叫saveUser介面會儲存在裡面
  • ACT_ID_INFO 儲存使用者的屬性資訊,setUserInfo介面的時候設定一key,value資訊儲存在其中
  • ACT_ID_GROUP 儲存新建立的Flowable組資訊,saveGroup會儲存在其中
  • ACT_ID_MEMBERSHIP 使用者和組的關係會存在裡面,使用者和組可以多對多
  • ACT_ID_PRIV 儲存可以使用的許可權,createPrivilege會新增一條記錄
  • ACT_ID_PRIV_MAPPING 儲存使用者id或組id與許可權的對映關係,addGroupPrivilegeMapping或者addUserPrivilegeMapping會新增一臺記錄
  • ACT_ID_TOKEN 使用者相關Token,saveToken會新儲存一條記錄

**備註:**可以看出來,Flowable官方提供的IDM在一定程度上也可以進行RBAC(Role-Based Access Control)的操作,只是許可權管理會複雜一點的時候,IDM就滿足不了我們的操作。

user -> user

group -> role

PRIV -> access control

自定義許可權管理

如果我們覺得預設的許可權管理滿足不了我們的需要,或者已經有自己的許可權管理系統,則需要額外處理。有2種可以與自己業務相容的方案:

  • 方案一:同步自己的許可權表資訊,適配Flowable的表結構,仍然使用IDM提供的服務介面去操作
    • 優點:對Flowable沒有侵入性,不需要引入額外的內容
    • 缺點:已經有許可權管理系統的時候,如果存在兩份資料可能有資料不一致的現象,增加額外的資料維護
  • 方案二:自己寫程式碼,實現IdmIdentityService介面,處理自己的許可權管理邏輯。官方提供了可以直接使用的LDAP整合方案,我們不一定使用LDAP,但是其中的程式碼實現比較經典,可以參考一下。
    • 優點:自定義實現,靈活,不管什麼許可權系統都可以寫適配
    • 缺點:如果其他組想接入Flowable,需要引入我們的許可權控制實現。

方案一

我們在上面已經說過Flowable許可權管理的幾張表的內容,按結構將我們的許可權資料匯入其中即可。但考慮到資料方面內容,可能也需要一定的程式碼開發量。

注意:

  • 資料結構相容性
  • 資料的一致性,許可權資料更新需通知,或定時拉取許可權資料

方案二

官方的IDM模組以及被單獨拆分出來,我們的實現的程式碼不會對Flowable的工作量有影響,另外IDM模組,只需要關心能否提供許可權控制即可。

以LDAP為例,在使用的時候只需使用正確的IDM配置器即可:

// 只需改動這一行的配置器即可
IdmEngineConfigurator idmEngineConfigurator = new LDAPConfigurator();
cfg.setIdmEngineConfigurator(idmEngineConfigurator);
    
ProcessEngine processEngine = cfg.buildProcessEngine();
IdmIdentityService idmIdentityService = idmEngineConfigurator.getIdmEngineConfiguration().getIdmIdentityService();
複製程式碼
實現

根據自己的業務需要,提供使用者的管理功能。關鍵部分:

  • 配置IdmEngineConfiguration引數
  • 實現IdmIdentityService,可繼承IdmIdentityServiceImpl
  • 實現UserQuery,可繼承UserQueryImpl
  • 實現GroupQuery,可繼承GroupQueryImpl
  • 實現PrivilegeQuery,可繼承PrivilegeQueryImpl

如果我們的已經有自己的許可權管理系統,在一定程度上相當於做自己的許可權管理系統的客戶端。

小結

在業務發展一段時間後引入工作流,採用第二種方案更合適一些。

  • 如果將自己的許可權系統資料匯入到Flowable的表中,在分散式系統中相當於兩份許可權管理,Flowable一份,自己的許可權管理一份。
  • 已經存在許可權管理服務的時候,主要就是供客戶端使用,將Flowable的許可權管理部分作為自己許可權管理的客戶端更符合分散式的設計,分散式系統中只有一個系統提供一種型別的服務,供其它系統使用
  • 至於LDAP,也是一種許可權管理的方案,如果內部有LDAP可以直接使用LDAP,如果沒有LDAP,寫相應的程式碼訪問自己的許可權管理系統也無大礙