1.基于角色的權限控制：role-based access control(RBAC)
2.兩大組織構件：People 和 Resources
而後者包含Application 和 OS
3.基本系統邏輯架構
Person <-> Authorization <-> Resources
4.系統基本架構
•ITIM Server 存儲安全管理業務和中央集權的使用者和資源管理
– Directory server 存儲使用者資訊群組織架構資訊
– Database server 存儲運作時臨時資料和曆史資料
• Web Server(可以與ITIM是一個伺服器，提供J2EE平台和Web服務)
• Tivoli Identity Manager adapters（用于與ITIM中心伺服器通信，分為agent-based 和agentless兩種，前者安裝運作在被管理機器上，後者則在IBM Tivoli Directory Integrator (TDI) 伺服器上使用（必須使用ssl安全連接配接））
5.Agent通過DARPA Agent Markup Language (DAML)進行通信，這是一種基于SSL至上的XML通信格式。
6.分布部署圖：
7.部署的幾個思路
設定service的優先級，将那些大量使用者使用的，經常有賬戶變更操作的Service視為高優先級。
設定Provisioning的類型，分為自動和手動，前者效率高，但是可能産生不必要的賬戶，而後者時效性不強。
考慮容量：使用者數，同時線上數，系統存儲容量，多長時間完成一個Action
考慮上線時間：企業中的需求對下線時間的要求。
簡單性和花費：盡量簡化部署。
考慮拓撲結構：将核心伺服器部署在安全基礎設定之後，保證安全。
考慮安全流程：根據公司的安全規程進行設計。
考慮特性：根據公司要求進行定制化服務。
考慮使用者身份導入：Identity Feeds
考慮中心使用者內建：Centralized User Repository 這個中心使用者內建要求讀多寫少，但是TDS在TIM中的讀寫基本是差不多的頻率，是以TDS不是實作這個功能的元件。
考慮Service和Adapter：哪些需要agent，怎麼部署，部署哪些特性，使用什麼連接配接
考慮賬戶：是不是在ITIM中建立一個使用者登入賬戶管理其要管理的賬戶。賬戶名是不是要有一個命名标準。
考慮密碼：密碼是不是要進行同步，密碼強度政策如何，密碼的修改方式是什麼。
考慮審計需要：多久要線上儲存審計資訊，離線呢，怎樣的審計是符合公司流程的。
考慮審批流程：審批流程的實作，是不是要根據使用者類型進行審批流程定制等。
考慮組織結構：使用者角色等等。
考慮界面定制化：根據公司要求進行界面的個性化定制。