把权限模型划分为页面访问控制权限和数据权限 ( 商业逻辑权限 ) 。其中，页面访问控制权限主要在于控制页面是否可以被访问，比如，管理员可以访问权限设置页面。数据权限主要是指是否有操作某个数据的权限，比如说组织机构中的部分问题，一个部门应该只看到本部门的数据，这就是数据权限，这个应该在业务逻辑中控制，而不是页面中。

本权限模型专注于页面访问控制，不涉及数据操作权限。使用用户、角色、资源和操作来控制实际的页面访问。同时，区别于一般的页面权限模型，本模型采用细粒度的权限控制，可以控制到页面的具体操作，很不是整个页面不加区分。所以，这样就可以在一个页面放置多个操作，方便于用户，同时又不失安全性。

考虑到权限在实际中很少变动，使用数据库的冗余设计，还有数据缓存等来提高效率。

用户： User

       Id 、 name

用户角色表（ 1 对多）：

       Id 、 userID 、 roleID

角色 : Role

       Id 、 name 、 description 、 defaultPage （系统初始化时，使用的登陆页？）

权限 (Role-Resource-Operation) ： Authority

       Id 、 role 、 resource 、 resourceURL （为效率考虑采用的冗余，等同 Resource 中的 url ，在实际验证中将使用该 url 来验证）、 operationID 、 operationName （为效率考虑，采用冗余，等同 Operation 中的 name ，实际验证中使用该操作名称来做验证）

资源： Resource

       Id 、 name 、 description 、 url

操作： Operation

       Id 、 name( 一般应改为英文，对应方法的名字 ) 、 description

BaseAction 中应该有一个 getMethodAuthMap （），得到方法和可用操作的映射。如果映射中找不到，则直接使用该方法名当作操作名称。如果方法映射找到了，但是为空，这意味着该方法对于任何用户都是可以访问的，不要求验证。子类可以继承和覆盖该方法，来实现特殊的权限逻辑。

权限操作应该允许复制已有的权限来生成新的权限。

在前端控制器中设置已有的对于某个资源的操作，放到 hashtable 中，比如 auth 。对于页面，使用表达式语言 EL 来限制实际的逻辑，比如如下要求对于当前页面要有 delete 权限：

       <c:if test=”auth.delete”>

       </c:if>

同时，在整体页面中，使用 struts 的 dispathAction 来做分发， url 形如 url?method=delete 在执行该方法之前，首先检查当前页面的这个权限 delete ，如果可以，则导向到正确的页面，否则导向到 accessDenied.do 页面（注意，该页面比较特殊，对于任何用户都应该是可以访问的，也就是前面的 getMethodAuthMap 返回为 NULL ）