隨著資訊化的迅猛發展，各個企業也加快了資訊化建設並引入大量的業務系統用於企業的業務管控。而隨著業務系統的逐步增多，各個業務系統之間的組織、崗位、使用者也變得愈加難以統一，企業中缺少統一的人員資訊管理。由此我們公司的統一身份認證平臺+應用整合平臺結合的
統一身份管理方案
應運而生。
IDM作為統一身份認證平臺，實現了5A管控，即
應用管控、統一使用者、統一認證、統一許可權和統一審計
用於解決企業的多應用無統一管控的局面。而ESB應用整合平臺，是一款強大的應用整合產品，配合IDM與其他業務系統進行資料對接，使得統一身份管理方案的靈活性更高。
整體設計
IDM做到應用管控、統一賬戶、統一審計、統一認證和統一許可權，其中應用管控在IDM中進行相關業務系統的管控，統一賬戶需要從HR進行資料同步，再從IDM配合ESB進行資料的分發實現統一賬戶，並在登入認證時實現人員賬號的統一認證和許可權，對業務系統的功能資源、資料資源和介面資源進行許可權的管控。下面是對於
資料同步、分發、認證和統一許可權
的流程說明。
1.資料同步
資料同步流程圖如下：
IDM作為一箇中間統一使用者中心需要將人員的資訊錄入到IDM中，並在IDM中進行人員資訊的管控處理，在這個過程中，ESB主要起到了在流程對接過程中將源頭資料進行處理，調整為IDM所需的資料資訊並呼叫相關介面錄入到IDM中。
1。在進行資料同步時，IDM需要一個具有權威的並且完整的人員資料，進行資料同步，透過呼叫IDM的人員組織的資料錄入介面同步到IDM中。
2。在實際的流程對接中，源頭系統未必會能夠給出符合IDM入參標準的資料，這時候就需要ESB作為轉換節點，將資料進行轉換處理，整合成IDM所需的資料資訊，呼叫IDM介面在錄到IDM中。
3。IDM接收到ESB給的同步資訊，並進行相關的資料整理，這時當其他業務系統想要獲取人員資料資訊，IDM就作為了一個源頭系統進行資料的下發處理。
2.資料分發
資料分發的流程圖如下：
在IDM中，其他業務系統想要獲取到我們的人員資訊資料，需要進行任務的推送，
IDM支援兩種資料分發的方式
：
1。業務系統提供任務ID獲取的介面，在IDM的內建流程呼叫功能，將taskId傳送至業務系統，業務系統內部根據taskId獲取資料，進行增刪改的資料管理。
2。對於無法提供任務獲取的業務系統，以及無法主動獲取任務ID的業務系統，就需要ESB將資料推送至業務系統中，業務系統提供他們的人員資訊寫入介面，在ESB中處理本次任務的資料資訊將資料寫入到業務系統中。
3。無論哪種的資料推送方式，都需要
將分發的日誌資訊情況回寫給IDM
，IDM記錄這次的分發資料情況。
當人員資訊下發成功後，業務系統會對人員資訊進行處理，包括資訊錄入，後續登入認證的人員校驗，如在IDM登入成功後，業務系統可以根據登入的人員資訊進行選擇放行。
3.統一認證
統一認證流程如下：
IDM作為統一身份認證平臺，其他業務系統在登入過程中，需要與IDM進行對接認證，也就是相當於IDM代替了各個業務系統的登入功能。
在統一認證的過程中，業務系統根據不同的情況進行相應的登入對接。
1。CAS用於統一身份認證技術，Web應用系統提供一種可靠的單點登入解決方法，在實現統一身份認證過程中，一般CAS Server登入成功後只會給業務系統返回一個登入賬號，但特殊情況需返回多個值，支援多種客戶端，安全可靠。
2。Oauth認證不會使第三方觸及到使用者的帳號資訊，不會程式碼侵佔的認證方式，透過認證平臺登入賬戶成功後，會從定向業務系統的頁面，呼叫Oauth介面獲取token和使用者資訊，從而業務系統可以透過使用者資訊及直接的認證方式進行登入認證，這樣就實現了Oauth模式單點登入模式。
3。認證擴充套件根據不同的認證需求，透過ESB開發相應的認證服務，進行相應的身份認證，對於認證擴充套件例如移動端、客戶端、web端的認證就需要額外進行三端認證的功能擴充套件，針對大型公司包含了許多子公司都進行統一認證時就需要用到分散式認證。
4.統一許可權
統一許可權流程圖如下：
在授權管理模組，當權限進行調整時會生成對應的操作，然後生成一個任務。生成任務後，可以透過任務ID推送給對應的業務系統，業務系統透過任務ID獲取對應的許可權資源資訊。
提交任務支援自動提交和手動提交，透過全域性變數進行配置
。
業務理解
IDM+ESB統一身份管理方案，用於解決眾多系統中組織、崗位、使用者無統一管理，企業缺乏統一的賬號安全管理策略，無法實現使用者管理、身份認證、審計等必不可少的安全措施，對此，在實際專案的實施前需要去調研客戶的需求，根據不同的需求情況給出相應的解決方案。
1.統一使用者
統一使用者中心，最根本的就是要對使用者資訊進行統一管控
，需要對源頭資料進行調研，瞭解客戶的人員、組織、崗位的資料情況，並進行分析和對比，與我們的系統資訊進行適配處理，在這個過程中，需要客戶能夠提出一個具有權威性的業務系統的資料這樣IDM作為中間產品將資料進行處理，或者給出一個人員組織崗位的匯入excel，將資料匯入到IDM中，這樣IDM會作為源頭資料進行資料管控。
想要獲取到資料資訊，業務系統還需要到IDM中進行註冊接入，在IDM統一對業務系統進行應用管控，業務系統透過註冊的賬戶和密碼來獲取tokenId呼叫資料資訊。
2.統一認證
統一使用者中心，在分發使用者資訊後，也可以透過IDM進行人員資訊的統一認證，即將IDM作為一個業務系統的登入功能進行使用者資訊的校驗和稽核，在做統一認證功能時，也是需要客戶提供相應的業務系統資訊，進行應用的配置註冊，對於可以進行oauth認證的業務系統，提供響應的url。
客戶需要給出當前的登入認證情況，根據實際的業務情況，給出Oauth認證的方式、CAS認證證、或進行相應的認證擴充套件。
3.統一許可權
統一許可權是對業務系統的功能資源、資料資源和介面資源的許可權資訊進行管控
，在對業務系統進行統一許可權的管控時，需要業務系統提供響應的初始化資料介面，並且保證業務系統對於功能資源、資料資源和介面資源有對應的授權功能，IDM會透過生成許可權任務將許可權資訊下發給業務系統中，實現對業務系統的許可權管控。
統一使用者
源頭系統透過呼叫ESB流程，將人員資料存入到IDM統一使用者中心，業務系統進行呼叫資料時，需要在IDM中進行相關的資訊註冊。
1.應用管控
對於想要獲取IDM的資料的業務系統，需要在應用配置中註冊業務系統的使用者名稱和密碼，用於後續獲取資料資訊，並且下發的任務資料也要有對應業務系統的分發許可權。在IDM首頁部分，應用
系統的分發統計
是根據業務系統的註冊配置進行排序顯示的。
組織、崗位、人員管理部分如果在進行下發時，要下發到對應的業務系統時，需要對對應的資料配置分發許可權，如果該資料沒有分發許可權業務系統是獲取不到資料的。
當業務系統與IDM做統一認證時，Oauth認證需要業務系統配置對應的應用域名。
統一許可權模組根據業務系統的不同，進行不同業務系統的許可權管控。
監控統計部分根據業務系統進行監控資訊的視覺化展現。
2.資料同步
資料同步，透過ESB連線源頭業務系統和IDM，源頭系統提供人員的資料資訊，在進行調研核實後，透過ESB將資料接收，並進行資料的整理、修改，調整為IDM資料同步所需的入參引數，在透過ESB呼叫IDM同步介面，將資料同步至IDM中。最終當源頭資料進行修改後，值需要呼叫同步介面，ESB+IDM會將該資料分發至其他業務系統中。
3.資料分發
當資料同步完畢後，IDM在本次對接流程的過程中就變為了源頭資料，而其他業務系統想要獲取到IDM的資料，需要提供響應的資料接取介面。
原則上業務系統需要提供一個能夠獲取taskId的介面，在獲取到taskId後業務系統利用token和taskId拿到本次任務的資料資訊。業務系統根據資料資訊對他們自己的資料進行增刪改的操作，最終將任務分發情況回寫給IDM。但是對於一些無法內部進行資料處理的業務系統，我們也可以提供ESB進行業務對接，可以在ESB中將資料獲取後，根據業務系統提供的介面，將資料寫入到他們的表中。
4.落地方案
1。針對源頭系統，需要將資料給到IDM系統，IDM+ESB支援根據不同情況對源業務系統進行資料局獲取；
2。當源業務系統不支援實時資料推送時，ESB可以開發定時流程，每隔一段時間對資料進行拉取，確保資料的及時性；
3。而源業務系統支援實時資料推送時，可以在修改資料後進行資料推送，呼叫ESB流程將資料同步至IDM中；
4。針對資料分發情況，業務系統可以提供任務獲取介面時，IDM會將該介面資訊記錄到BPM中，在BPM呼叫該介面給到taskId，在給到taskId後業務系統根據資料情況進行增刪改的操作並呼叫回寫日誌回寫給IDM中；
5。針對部分業務系統無法提供任務獲取介面，但是可以提供對應的資料增刪改的介面，對於任務資訊獲取需要由ESB進行處理，透過IDM中的BPM工程呼叫ESB流程並呼叫對應的介面資訊，然後將回寫資訊返還給IDM中；
6。對於連線口都無法提供的業務系統，則需要提供對應的資料表，在ESB中進行介面註冊，針對業務系統表的增刪改查介面生成後，在透過IDM中的BPM工程呼叫ESB流程，將資料透過服務寫入到業務系統的表中。
統一認證
IDM在認證過程中需要面臨很多的問題、如與形式多樣（
客戶端、web端、移動端
）的認證接入，為此IDM需要有多種認證對接方式、保證系統認證的快速接入，完成統一身份認證平臺的快速搭建和執行。為此IDM具備了多種的認證方式，以針對不同情況去使用。
1.Oauth認證
Oauth認證作為當前主流的對接方式
、市場上絕大多數系統都可以支援Oauth認證，並且Oauth認證比起其他認證方式理解更加的簡單、使用起來更加的方便，並且OAuth認證方式沒有涉及到使用者金鑰等資訊，更加安全和靈活，在不侵入業務系統進行改造的情況下，實現業務系統的登入。
2.cas認證
cas認證更適用於和多個業務系統進行一對一的對接cas認證中cas server獨立部署
，cas client與受保護的客戶端應用部署在一起，透過以 Filter 方式保護受保護的資源，並且在傳輸採用ssl協議，可以確保ST和TGC的安全性，並且生成的ticket相對於使用者也是透明的，並且提供了Proxy （代理）模式，可以適應更加高階、複雜的應用場景。
3.三端認證
三端認證可以解決第三方門戶的系統整合
，同時可在移動端、web端和客戶端實現自由切換和認證，在門戶內部可以呼叫其他認證方式，實現統一登入和統一認證，配合其他業務系統的自由認證登入更可以班組移動辦公場景。
4.分散式認證
分散式認證針對大型的集團公司
，可以保證客戶方如果有其他子分公司時，透過集團認證以及負載均衡及高可用的情況，子公司部署獨立的認證節點，實現子公司內部辦公在子公司區域網內部進行認證，提高認證的響應速率。
5.落地方案
1。針對Oauth認證，首先需要明確業務系統是否支援oauth認證的認證方式，在當今情況下，大多數系統都會支援業務系統，因此在進行對接過程中會優先選擇該認證方式，並且該認證方式更加的適合和IDM進行一對一的認證；
2。cas認證是最早的認證方式，這種認證方式主要是針對比較老的業務系統，對於業務系統無法支援oauth認證，那麼就需要透過cas認證進行對接。但是如果業務系統既支援oauth認證又能夠支援cas認證，比較推薦進行oauth認證進行對接；
3。其他認證方式，針對不同的業務系統情況進行登入認證：
1）三端認證：業務系統包含了移動端、客戶端、web端三端的登入方式，在ESB開發認證服務介面，三端登入時呼叫ESB認證介面進行呼叫登入，透過這種整合的方式統一進行登入認證；
2）分散式認證：分散式認證針對大型的公司，在大型的集團性公司都會建立全集團的區域網，集團與子公司之間透過專線聯通，在分散式認證的情況下，子分公司進行獨立的認證部署，減輕集團的認證壓力，保證壓力的均勻分佈和系統的高效能使用。
統一許可權
針對於客戶的許可權統一管控的需求，在統一許可權模組進行相應的許可權管控，統一許可權能夠以使用者身份為中心，解決企業當前許可權管理面臨的開通難、查詢難、回收難和管理難的問題，實現
企業業務許可權的集中化、標準化、安全化
，加速企業許可權管理建設，降低對許可權的管理與維護成本。
1.角色管理
角色管理模組用於對業務系統的實際角色和標準角色進行統一管控，對於對接我們的業務系統，他們的角色資訊由IDM進行增刪改的操作，在整個統一許可權模組中，
組織和人員可以在業務系統中選擇配置，是否繼承
。在為角色配置人員資訊時，可以選擇是人員管理中的人員或是業務系統的人員。
2.許可權資源
許可權資源模組用於解決對業務系統的功能資源、資料資源和介面資源的管控
，在呼叫業務系統的全量資源介面後，後續對於功能、資料和介面資源的增、刪、改都由IDM進行管控，隨著使用時間的增加，最終會將資料清洗成IDM的標準資料格式。
3.授權管理
在授權管理模組，IDM透過對功能資源、資料資源和介面資源
進行實際角色、標準角色、使用者和組織進行授權
，在新增完成後也會生成對應的任務資訊，任務生成後新增對應的流程，將許可權資訊下發給各個業務系統中。
4.落地方案
統一許可權模組是在IDM中對業務系統的資料資源、介面資源和功能資源進行管控。
首先業務系統需要滿足各個部分資料的授權功能，業務系統需要滿足對這三個部分的許可權管控。
其次，業務系統需要提供對資料的初始化匯入介面，將資料匯入到IDM中在IDM進行統一管理。
心得總結
IDM+ESB的專案是我正式參與的第一個專案，在此工作期間，對於IDM業務場景的使用，業務系統的對接，統一身份認證的處理都有了新的認知，與客戶的溝通互動，處理問題的思維也有了新的提升。
1.提高認知
本次的專案落地理解我其實只是懂得的一些皮毛，對於未來的我來說要成為專案經理這些是遠遠不夠的。而想成為專案經理就要做好對應的覺悟，必須要
提高自己的認知和知識儲備
，更加的深入瞭解公司產品和解決方案，逐步的提升完善自己。這樣才會讓自己成長從而提升能力，把握住每次專案的機會，抓住在專案中學到的東西充實和完善自己，只有提升自己的能力才不會被淘汰。
2.自我反思
目前自己對於認證的方式僅僅只是停留在了使用的方式上，真正的實際應用對接，自己只有一個抽象的概念，還沒有一個成熟的意識。在與客戶進行對接的過程中雖然可以告訴他們如何去對接，但是也是因為自己沒有真正參與過實際的認證對接，對於對接過程出現的問題，沒有很好的應對措施，總會在這種情況下顯露自己的不足。
3.經驗積累
對於專案工作內容，不能一味總是靠著經驗來做事每個專案都要有沉澱，這種沉澱是
對專案的回顧和覆盤
，也是對自己知識掌握的一個查缺補漏。有些臨時處理和快速學習的內容，雖然在當時的時間點處理了但後續在回顧的時發現，當時掌握的只是皮毛，在專案中遇到的問題一定要做到舉一反三，因為很多情況下一個相同處理方式的問題，很少會出現第二次的情況。
在處理問題前，一定要先儘量把所有能協調到的資源協調好，避免在發現卡住的問題時，因為資源不足而出現長時間等待的尷尬情況。產品是從專案中來到實踐中去的，作為一名專案人員需要的則是更多的專案經驗積累。在工作中，總結自身的不足，多反思多思考。瞭解自己的缺點並攻克它們逐步豐富自己的積累和沉澱。
本文由@數通暢聯原創，歡迎轉發，僅供學習交流使用，引用請註明出處！謝謝~”
