权限翻译

权限管理（一）概念和模型

权限管理属于信息安全的内容，套用Windows信息安全的内容，信息安全包括下面六个要

素：安全策略（CorporateSecurityPolicy）、用户认证（UrAuthentication）、访问控制（Access

Control）、加密（Encryption）、管理（Administration）、审计（Audit）。培训课程主要包括了

Siebel的访问控制、用户认证、和所谓的网络安全。网络安全包括了加密通讯、用户ssion

的密码保护、防火墙支持等内容，实际上是网络相关具体解决方案。其中和业务关系最紧密

的是访问控制AC，也可以称为权限管理。

根据RBAC（Role-BadAccessControl）模型，权限管理包括几个对象：

*用户（ur），可以映射为系统的某个使用者；

*控制对象（object）或资源（resource）：即对什么东西进行权限管理。比如Siebel中的

Account，Opportunity，ServiceRequest的每个实例（指的是customerdata，不是这些business

entity本身）。控制对象本身是可以有层次结构的，比如某个Account可能附有一些

Opportunity等；

*操作（operation）：对控制对象可以进行操作，比如可见性、新增、删除、修改、查询；

*特权（privilege）或者许可（permission），表示一种“资源+操作”的组合，即对什么对象能

做什么事情。

*角色（role），即“用户+特权”的组合，表示什么人能做有什么权力；

*会话（ssion），表示用户与激活的角色集合之间的映射，在系统运行的时候，一个用户

可能有多个角色。

*用户组（group）：是一个或者多个用户的聚合。这个RBAC里没有，是我加的，因为考

虑到对单个用户进行授权可能导致工作量巨大。

基于Siebel这样的COTS软件，我想权限相关的职责可以这样划分：

*dev：软件本身的开发，提供对象定义和对象操作定义的能力，还应该提供某些权限能做

什么事情的控制机制。

*config：使用软件提供的能力定义新的对象、该对象相关的操作。

*admin：管理：定义特权，定义角色（即用户和特权的关系）

*using：使用，基于角色访问对象和功能，受到权限管理控制机制的控制。

值得商榷就是是否应该由admin定义特权，实际生产中应该由业务需求者定义，admin仅仅

是实现这个定义；

权限管理（二）Siebel的实现

Siebel权限管理包括下面的内容：

*对View的访问控制

Siebel中View是用户展现层的一个重要对象，一些逻辑上相关的业务实体被放在一

起，定义了一套展现的方式就成为了View。其中每个业务实体可以展现为一个Applet。一

个View可以包括多个Applet。Siebel将View作为一个控制对象，而将Ur做为用户，使

用Responsibility定义View和Ur之间的关系。如果一个Ur的Responsibility中包括了一

个View，那么这个Ur就可以访问这个View。在Responsibility中可以制定访问的方式是

ReadOnly还是Full（允许修改）。

*对用户数据（customerdata）的访问控制

为了支持不用的ur登录入同一个View看到不同的用户数据，Siebel引入了Position

的概念，可以翻译成职位，但是实际含义不一样。Position是有层次关系的，Position的层

次关系体现了数据可见性的层次关系。比如有个Position叫销售组长，管理若干Position叫

销售代表，销售代表每个人都有不同的Opportunity，可以实现这样的数据可见性方案：每

个销售代表只能看到自己的Opportunity，而销售组长可以看到他手下所有销售代表的

Opportunity。Siebel中可以将Employee对象加入Position中（不过我目前没有搞清对于权限

管理，Ur和Employee有什么区别，我觉得权限管理可以认为都是针对Ur的。）Position

可以有树形的结构。

此外，Siebel还引入了Orgnization的概念，Orgnization是一种具有权限控制需求的的

Division，而Division是Siebel用来体现组织结构关系对象。比如某公司下面有几个部门，

就可以定义一个Division代表公司，然后每个部门定义一个Division，这些Division都是公

司Division的子对象。如果某个Division有特别的数据访问控制要求，就可以通过设置一个

flag将Division标记为一个Orgnization。Position强制要求被分配给一个Division。

Orgnization/Division可以有树形的结构。

除了Orgnization和Position，数据访问控制还可以针对个人，即Person。

对于不同的类型的BC(businesscomponent,可以理解为一个businesntity的逻辑实

体)，可以定义不同的数据访问模式，控制对该BC类型的用户数据的访问。访问模式包括：

针对Ur，针对Position，针对Orgnization。Orgnization、Position本质上说是不同Ur组

合模式，几种差别展示方式在于处理树形结构的方法差异，Orgnization更偏向于组织，而

Position更偏向于人，即reporting的关系。可以将Orgnization和Position的差异理解为针对

不同的视角将人进行分组。Siebel的这种实现可能是支持解决矩阵式的管理模式吧。

对于每个View，都定义了一个数据显示的方式。这个数据显示方式是基于View的主

要Applet所属的BC的数据访问模式，Siebel预定义了几种View的数据显示方式，包括：

-MyView：显示基于ur_id和当前活动的position，直接分配到Ur的记录；(记录

owner=用户ur_id或者记录position=用户当前的activeposition)

-MyPersonalView：显示基于Ur拥有的记录；(记录owner=用户ur_id)

-MyTeam'sView(Manager'sView)：基于Position的，允许组长看到自己组员的记录。

(我猜测是记录的position=用户position，或者记录的[主]position是用户的position的子孙。)

-AllView：显示用户所属的Orgnization的的记录；(用户Org=记录Org）

-AllAcrossMyOrgnizationsView：显示用户所属的Orgnization和该Orgnization的所

有子Orgnization的记录；(用户的Org=记录的Org，或记录Org是用户Org的子孙Org)

-AllAcrossOrganizationsView：显示所有有拥有者的记录；（filter="ownerisnotnull"）

-AdministrationView：显示所有的记录，即使没有一个拥有者；（就是列出数据库所

有记录，没有任何记录）

（括号内是我自己的理解，不一定对）

Siebel还有一种特别的TeamAccessControl，某一条记录可以关联到一组Orgnization、

Position或者Person，其中一个作为Primary。

*对配置数据（masterdata）的访问控制

Siebel系统还有一些预定义的masterdata，其中最有名的就是产品(product)，即一个

企业提供给用户的产品或者服务。masterdata通过Catelog/Category的目录结构组合在一起。

可以向Category中附加Product的实例。用户对于master访问的方式是通过访问组（Access

Group）。访问组可以包括：Orgnization、Position、Houhold、UrList这几个Ur的组合，

从而最终和Ur结合在一起。只有private的Catelog/Category需要设置访问组，public的不

用。

权限管理（三）Siebel与RBAC的对象映射

Siebel系统中的权限管理与RBAC没有完整的对应关系，但是可以分析出一定的联

系。根据我的思考做了一些总结，可能存在问题，权作抛砖引玉吧：

对于customer数据：

*Siebel的Ur可以和RBAC的Ur对应；

*Siebel的Orgnization、Position都是Ur的聚合，实际上是Group的概念；

*Siebel的Responsibility和RBAC的role有一定的关系，但是又有很多差异；

*Siebel的customer数据可以认为是RBAC的object/resource；

*Siebel的View可以认为是RBAC的privilege，但是也不是完全对应；

*Siebel没有和操作对应的实体，Siebel默认只有两种操作“只读”数据以及“完全控制(包括增

加、删除、修改、查询)”数据，这二者是在Responsibility中设置的。

对于master数据：

*Siebel的Ur可以和RBAC的Ur对应；

*Siebel的Orgnization、Position、Houhold、UrList、AccessGroup都是Ur的聚合，

实际上是Group的概念；

*Siebel的Catelog/Category对应了RBAC的role；

*Siebel的masterdata可以认为是RBAC的object/resource，Catelog/Category结构同时也是

对于masterdata的组织模式；

*Siebel没有和RBAC的privilege对应的实体；

*Siebel没有和operation对应的实体，应该都是完全控制；

几点理解：

-Siebel是支持Category的树形结构的，对应RBAC模型中的HierarchicalRBAC，

但只能用于masterdata。相应要求AccessGroup本身也有树形结构，并且需要和

Catelog/Category满足一定的关系。个人认为Catelog/Category实际上既是object/resource的

组织方式，又同时是privilege的组织方式，承担了两个职责；

-Siebel没有支持RBAC的StaticSeparationofDuty和DynamicSeparationofDuty，

即在权限分配、或者用户权限激活的时候都没有进行冲突检测。Siebel的实现仅仅是对于拥

有多个Responsibility的用户，激活的时候取所有Responsibility的并集，即使存在冲突。比

如，某个用户在某个Responsibility中对于某View是完全控制，另外一个Responsibility对

同样的View是只读，则实际激活的权限是完全控制；

-Siebel没有支持将Responsibility授权给Group（即Position，Orgnization，UrList

等）；

-Siebel授权没有有效期控制；