1.基于角色的权限设计
这种方案是最常见也是比较简单的方案，但是通常这种设计就足够了，所以微软设计了这种方案的通用做法。这种方案不控制每个操作，只是在程序中3D场景，根据角色控制操作的权限；此处不再赘述。
2. 基于操作的权限设计
在这种模式下，每个操作都记录在数据库中，并且用户是否具有操作权限也记录在数据库中。
3.基于角色和动作的权限设计
我们正在添加 Role 和 RoleAction 表，这样我们可以减少 UserAction 中的记录，使设计更加灵活。但是，这种方案在用户需求的考验下可能不够灵活。例如，当用户请求临时授予普通员工操作权限时，我们需要添加一个新的用户角色，但是这种用户角色是不必要的，因为它只是一个临时角色，如果添加一个角色也需要在撤销这个普通员工权限时删除这个角色权限管理设计角色，我们需要设计一个更合适的结构来满足用户对权限设置的要求。
4.2、3组合的权限设计，其结构如下：
新增UserAction表，使用该表为特殊用户添加权限，表中有一个字段HasPermission判断用户是否有某项操作的权限，表中记录的权限优先级高于UserRole 记录的用户权限。这样，在应用中，我们需要通过UserRole和UserAction表中的记录来判断权限。
这不是故事的结局。有可能用户也会给出这样的要求：有些记录对某个action操作的对象有权限，而对其他记录没有权限，比如一个内容在管理系统中，用户有修改某些频道的权限，但无权修改其他频道。这时候，我们需要设计一个更复杂的权限机制。
5.对于同一个实体（资源）用户可以对某些记录有权限，但对其他记录没有权限：
对于这样的需求，我们需要为每个不同的资源创建一个权限表。在上图中，分别为 Content 和 Channel 资源创建了 UserActionContent 和 UserActionChannel 表来定义用户是否可以访问记录。有权限；这种设计可以满足用户的需求，但不是很经济。 UserActionChannel和UserActionContent中会有很多记录权限管理设计角色，但在实际应用中，并不需要记录所有记录的权限信息。有时它可能只是一个规则。例如，什么级别的人对根频道有权限；这时候我们可以定义一些规则来判断用户权限，下面就是这个设计。
6.权限设计涉及资源、权限和规则
在这个设计中，没有了角色的概念，只有程序中的Rule类定义了用户是否有权限操作某个对象。
