权限管理（一）概念和模型
权限管理属于信息安全的内容，套用Windows信息安全的内容，信息安全包括下面六个要素：安全策略（Corporate Security Policy）、用户认证（User Authentication）、访问控制（Access Control）、加密（Encryption）、管理（Administration）、审计（Audit）。培训课程主要包括了Siebel的访问控制、用户认证、和所谓的网络安全。网络安全包括了加密通讯、用户session的密码保护、防火墙支持等内容，实际上是网络相关具体解决方案。其中和业务关系最紧密的是访问控制AC，也可以称为权限管理。
根据RBAC（Role-Based Access Control）模型，权限管理包括几个对象：
* 用户（user），可以映射为系统的某个使用者；
* 控制对象（object）或资源（resource）：即对什么东西进行权限管理。比如Siebel中的Account，Opportunity，Service Request的每个实例（指的是customer data，不是这些business entity本身）。控制对象本身是可以有层次结构的，比如某个Account可能附有一些Opportunity等；
* 操作（operation）：对控制对象可以进行操作，比如可见性、新增、删除、修改、查询；
* 特权（privilege）或者许可（permission），表示一种“资源+操作”的组合，即对什么对象能做什么事情。
* 角（role），即“用户+特权”的组合，表示什么人能做有什么权力；
* 会话（session），表示用户与激活的角集合之间的映射，在系统运行的时候，一个用户可能有多个角。
* 用户组（group）：是一个或者多个用户的聚合。这个RBAC里没有，是我加的，因为考虑到对单个用户进行授权可能导致工作量巨大。
基于Siebel这样的COTS软件，我想权限相关的职责可以这样划分：
* dev：软件本身的开发，提供对象定义和对象操作定义的能力，还应该提供某些权限能做什么事情的控制机制。
* config：使用软件提供的能力定义新的对象、该对象相关的操作。
* admin：管理：定义特权，定义角（即用户和特权的关系）
* using：使用，基于角访问对象和功能，受到权限管理控制机制的控制。
值得商榷就是是否应该由admin定义特权，实际生产中应该由业务需求者定义，admin仅仅
是实现这个定义；
权限管理（二）Siebel的实现
Siebel权限管理包括下面的内容：
* 对View的访问控制
      Siebel中View是用户展现层的一个重要对象，一些逻辑上相关的业务实体被放在一起，定义了一套展现的方式就成为了View。其中每个业务实体可以展现为一个Applet。一个View可以包括多个Applet。Siebel将View作为一个控制对象，而将User做为用户，使用Responsibility定义View和User之间的关系。如果一个User的Responsibility中包括了一个View，那么这个User就可以访问这个View。在Responsibility中可以制定访问的方式是Read Only还是Full（允许修改）。
   
* 对用户数据（customer data）的访问控制
      为了支持不用的user登录入同一个View看到不同的用户数据，Siebel引入了Position的概念，可以翻译成职位，但是实际含义不一样。Position是有层次关系的，Position的层次关系
体现了数据可见性的层次关系。比如有个Position叫销售组长，管理若干Position叫销售代表，销售代表每个人都有不同的Opportunity，可以实现这样的数据可见性方案：每个销售代表只能看到自己的Opportunity，而销售组长可以看到他手下所有销售代表的Opportunity。Siebel中可以将Employee对象加入Position中（不过我目前没有搞清对于权限管理，User和Employee有什么区别，我觉得权限管理可以认为都是针对User的。）Position可以有树形的结构。
      此外，Siebel还引入了Orgnization的概念，Orgnization是一种具有权限控制需求的的Division，而Division是Siebel用来体现组织结构关系对象。比如某公司下面有几个部门，就可以定义一个Division代表公司，然后每个部门定义一个Division，这些Division都是公司Division的子对象。如果某个Division有特别的数据访问控制要求，就可以通过设置一个flag将Division标记为一个Orgnization。Position强制要求被分配给一个Division。Orgnization/Division可以有树形的结构。
      除了Orgnization和Position，数据访问控制还可以针对个人，即Person。
      对于不同的类型的BC(business component,可以理解为一个business entity的逻辑实体)，可以定义不同的数据访问模式，控制对该BC类型的用户数据的访问。访问模式包括：
针对User，针对Position，针对Orgnization。Orgnization、Position本质上说是不同User组合模式，几种差别展示方式在于处理树形结构的方法差异，Orgnization更偏向于组织，而Position更偏向于人，即reporting的关系。可以将Orgnization和Position的差异理解为针对不同的视角将人进行分组。Siebel的这种实现可能是支持解决矩阵式的管理模式吧。
   
      对于每个View，都定义了一个数据显示的方式。这个数据显示方式是基于View的主要Applet所属的BC的数据访问模式，Siebel预定义了几种View的数据显示方式，包括：
      - My View：显示基于user_id和当前活动的position，直接分配到User的记录；(记录owner=用户user_id 或者 记录position=用户当前的active position)
      - My Personal View：显示基于User拥有的记录；(记录owner=用户user_id)
      - My Team's View(Manager's View)：基于Position的，允许组长看到自己组员的记录。(我猜测是记录的position=用户position，或者记录的[主]position是用户的position的子孙。)
      - All View：显示用户所属的Orgnization的的记录；(用户Org=记录Org）
      - All Across My Orgnizations View：显示用户所属的Orgnization和该Orgnization的所有子Orgnization的记录；(用户的Org=记录的Org，或记录Org是用户Org的子孙Org)
      - All Across Organizations View：显示所有有拥有者的记录；（filter="owner is not null"）
      - Administration View：显示所有的记录，即使没有一个拥有者；（就是列出数据库所有记录，没有任何记录）
      （括号内是我自己的理解，不一定对）
   
position职位      Siebel还有一种特别的Team Access Control，某一条记录可以关联到一组Orgnization、Position或者Person，其中一个作为Primary。
* 对配置数据（master data）的访问控制
      Siebel系统还有一些预定义的master data，其中最有名的就是产品(product)，即一个企业提供给用户的产品或者服务。master data通过Catelog/Category的目录结构组合在一起。可以向Category中附加Product的实例。用户对于master访问的方式是通过访问组（Access Group）。访问组可以包括：Orgnization、Position、Household、User List这几个User的组合，从而最终和User结合在一起。只有private的Catelog/Category需要设置访问组，public的不用。
权限管理（三）Siebel与RBAC的对象映射

        Siebel系统中的权限管理与RBAC没有完整的对应关系，但是可以分析出一定的联系。根据我的思考做了一些总结，可能存在问题，权作抛砖引玉吧：
对于customer数据：
* Siebel的User可以和RBAC的User对应；
* Siebel的Orgnization、Position都是User的聚合，实际上是Group的概念；
* Siebel的Responsibility和RBAC的role有一定的关系，但是又有很多差异；
* Siebel的customer数据可以认为是RBAC的object/resource；
* Siebel的View可以认为是RBAC的privilege，但是也不是完全对应；
* Siebel没有和操作对应的实体，Siebel默认只有两种操作“只读”数据以及“完全控制(包括增加、删除、修改、查询)”数据，这二者是在Responsibility中设置的。
对于master数据：
* Siebel的User可以和RBAC的User对应；
* Siebel的Orgnization、Position、Household、User List、Access Group都是User的聚合，
实际上是Group的概念；
* Siebel的Catelog/Category对应了RBAC的role；
* Siebel的master data可以认为是RBAC的object/resource，Catelog/Category结构同时也是对于master data的组织模式；
* Siebel没有和RBAC的privilege对应的实体；
* Siebel没有和operation对应的实体，应该都是完全控制；
几点理解：
        - Siebel是支持Category的树形结构的，对应RBAC模型中的Hierarchical RBAC，但只能用于master data。相应要求Access Group本身也有树形结构，并且需要和Catelog/Category满足一定的关系。个人认为Catelog/Category实际上既是object/resource的组织方式，又同时是privilege的组织方式，承担了两个职责；
        - Siebel没有支持RBAC的Static Separation of Duty和Dynamic Separation of Duty，即在权限分配、或者用户权限激活的时候都没有进行冲突检测。Siebel的实现仅仅是对于拥有多个Responsibility的用户，激活的时候取所有Responsibility的并集，即使存在冲突。比如，某个用户在某个Responsibility中对于某View是完全控制，另外一个Responsibility对同样的Vi
ew是只读，则实际激活的权限是完全控制；
        - Siebel没有支持将Responsibility授权给Group（即Position，Orgnization，UserList等）；
        - Siebel授权没有有效期控制；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。