最近，在做一个文件管理的东东，拟用asp.net开发，b/s架构。前台展示没什么问题，主要是权限这一块比较复杂，查了不少资料，总体感觉有些欠缺，不能完美的满足需要。
本人是一个对code有着特殊爱好的人，本来是一个很小的系统，但为了做的完美，现扩展性的做一番探讨，现将自己对于权限控制方面的一些想法记下，希望大家一起学习、提高。
一、基本情况
1、公司有十几个部门，文件有许多分类，每个部门需要在各个分类提交文件，进行管理。
2、根据文件的适用范围，一部分文件的审核需公司部门审核，另一些只需要部门自已审核就OK了。
3、对于发布文件的查看权限需进行相应的控制，就是要指定哪些部门只能查看哪些文件。
4、为减轻工作负担，每个部门可能有多人在维护信息。
基本的情况就这些了，简单明了，可是做起来就不那了容易了。既然是想设计一个通用的权限控制系统，就扩展一下，将文件发布的审批、修改流程设计成工作流程，也即可以自定义，并可完整地的记录各种修订信息。
基于这种思考设计的权限控制，能算得上是通用的权限系统吗？
二、系统架构
1、基本要素：
资源(Resource)：用户操作产生产出（信息）的根本性、源头性条件，比如文件的分类，或是一个流程模板。
产出(Product)：用户在资源上操作产生的信息，比如用户提交的文件。
用户(User)：使用系统的人，参观用户、操作用户等。
角色(Role)：一组职责（权限）的集合，比如文件的审核者。
位置(Position)：现实中的组织机构或岗位。
权力(Power)：使用资源的权限。
职责(Responsibility)：对产出进行加工的权限。
初步设想划分为7个基本要素，好象比较晦涩难懂。呵呵，我也不知道对不对，逐步解析吧，不怕反复，只希望到最后能得到想要的东西。
２、基本原则：
系统权限的控制分为资源权限和产出权限，互不干绕，分开控制。位置在系统中是用户的集合，每个位置可能有多个用户，一个用户也可能属于多个位置。位置以树状结构组织，符合现实中的组织机构设置。角色是职责的集合，适用于对产出的控制。用户通过角色对产出进行操作，而不是通过位置。下层位置的所有产出其上层位置均可见。资源分配可到位置，再由位置分配到用户。
暂时就这些吧，可能会修改，也许会增加。
３、控制解析：
用户查看面向发布的信息（文件）（完整的，不是处于处理中的，也即不使用流程控制的，前台的）：
只需控制到分类（资源）：用户登陆后，系统根据用户的识别号取用户的位置，根据用户的位置得到用户对资源（分类）的权力，从而决定用户是否对某一资源上的产出有权查看。
需要控制到单个文件（信息）：首先使用上一条验证，然后根据文件附带的查看权限信息来控制查看。此信息指定到位置，不到用户，因为是面向发布的信息。
用户后台管理信息（后台操作）：
取得自己可操作的产出（信息或文件）：用户登陆后，根据用户的识别号得到用户的位置，根据位置取得此位置及所有子位置的用户，根据这些用户取得所有的产出（信息或文件）。取出的产出包括可操作的和不可操作的。
