标识权限
因为后台的访问控制都是基于Action级别 的控制，而我们使用系统都是以功能模块为最小单位的控制，所以我们首先需要建立一个Action和功能块的对应关系，如：“创建用户”功能对应的Action是“Create”。由于开发人员的差异有时候这种对应的关系很难得到保证。应该避免一个Action操作多种功能，这对与基于Action级别的访问控制不利。一般不存在一个操作对应多个Action。这样我们建立的Action和功能映射表就是一一对应的了，完全可以使用Controler+Action的名称来作为功能的权限标识，但是我们经常有出现重载的Action在GET和POST请求中，所以我们最终使用Controler+Action+RequestType。
接下来，我们需要将角色和功能关联起来。这样在权限树中，我们以中文描述，实际以其权限标识和角色标识关联起来。
数据库设计
流程图：
后台访问控制
在首次验证用户名和密码时，应该将该用户所有的角色的权限的标识无重复的存储在该用户的Session中。有时候为了避免多表查询带来的性能问题，我们可以在用户表中冗余的存储其所有的权限标识。
我们将所有需要权限的Action都使用扩展了过滤器的的属性标识，这样在执行Action之前就会验证用户的权限，通过获取用户当前访问的Controler和Action名，查找保存到用户Session中的权限标识集合就可以确定其是否有访问权限了。
视图访问控制
我们虽然在后台功能访问上做了决定性限制，但为了用户体验度，我们还需要控制视图级的功能显示和隐藏，用户没有 权限的功能块，不应该显示在当前用户视图中。这个在MVC中，只能通过在视图中写if...else...来判断了。至于判断的条件还是功能的“权限标识”，看当前用户Session权限标识集合中是否存在即可。
身份验证-双证模式
参见“双证模式”。
票证：我们设计一个独立票证发放类，提供简单和安全两种票证生成方法，简单票证可以易于受到“会话劫持”攻击，但生成效率高，使用GUID即可。使用安全票证，就是将变数大的随机信息，如用户浏览器和IP、时间、随机数等信息作为产生票证的参数，同时在服务端Session中保存其浏览器、IP等客户端信息，以便核对用户的浏览器和IP信息是否一致，如果不一致说明此请求为黑客“会话劫持攻击”行为。
密码加密：使用标准的MD5加密策略，MD5“雪崩效应”高，且不可解密。只有在极端情况下使用超级计算机通过“碰撞”才能解密。普通计算机几乎不可能产生有效碰撞。(更正：2005年王晓云教授已使用普通微机就能在短时间内产生一个有效碰撞。估计可以使用SHA-2了。)
为提高性能，以上两个类使用“单例模式”。
关键代码：