作者：gnuhpc
出处：http://www.cnblogs.com/gnuhpc/
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中建立一个用户登录账户管理其要管理的账户。账户名是不是要有一个命名标准。
考虑密码：密码是不是要进行同步，密码强度策略如何，密码的修改方式是什么。
考虑审计需要：多久要在线保存审计信息，离线呢，怎样的审计是符合公司流程的。
考虑审批流程：审批流程的实现，是不是要根据用户类型进行审批流程定制等。
考虑组织结构：用户角色等等。
考虑界面定制化：根据公司要求进行界面的个性化定制。