思考这个问题有点点时间了，其实我想要的效果并不只是用户登录之后，是否有权限访问某个网页，而是涉及到WEB服务器上的所有的URI资源的访问控制。比如说，在我的WEB服务器上的根目录下现在有一个1.jpg的文件，那么当用户在浏览器中输入http://www.***.com/1.jpg的时候，也就是说，他想直接访问这张图片的时候，如果系统判断他有权限访问该图片，则会在浏览器中显示出这张图片（如果是其他非MIME类型的话，可能是弹出下载对话框），否则则显示一把红叉，或者打印相关的提示信息。
这样的需求可能就没有办法在网站的应用程序里面实现了，因为在请求1.jpg这个文件的时候，并没有涉及到网站应用的任何逻辑，而是在WEB服务器承载程序（IIS，apache）接到请求报文之后，如果对应的请求文件在WEB服务器承载程序拥有读权限的话，那么则返回这个文件，否则打印的是WEB服务器承载程序的拒绝请求信息，通常被请求的文件在WEB服务器承载程序的权限应当是继承操作系统。
但事实上我参考了网络上面，关于图片的防盗链系统的一些实现方案，大都是通过判断HTTP请求报文中的UrlReference信息是否为本站来实现。参考：http://www.tracefact.net/Asp-Net-Architecture/Introduction-to-Http-Handler.aspx
这篇文章给出了一种解决方案，按照他的方法，如果自己实现.net Framework提供的IHttpHandler接口的话，可以手动的对HTTP请求进行处理。通过对HTTP请求信息的判断，然后作出相应的逻辑。
这种方案对于一般的防盗链应用也就够了，但是对于访问权限控制系统，不得不考虑到有恶意的情况。比如客户端是非标准浏览器， 例如自己写的一个HTTP请求程序，其目的是自己构造HTTP请求报文，那么这样的程序完全可以伪装UrlReference和Host为同一主机。假设URI为http://www.***.com/file1的文件，它授权用户A具有读权限，那么我们就不能通过判断请求报文的UrlReference来确认是否能够将file1文件暴露出去。因为用户B可能不具有访问file1文件的权限，但是可能具有访问引用了file1文件的file2文件的权限，而file2通常是.aspx文件。
和同学讨论了一下，如果采用基于角色的访问控制思想，可以弥补防盗链方法的不足。大概思路就是做一个服务器承载程序的插件，然后所有的HTTP请求都通过那个插件来处理，登陆后，信息写到Session中，获取请求的文件ID，再查询表判断该用户是否具有访问该文件的权限，如果有则返回文件，否则返回错误信息。如果基于Cookie的Session是安全的话，这种方法可以很好的弥补防盗链方法的不足。
稍微总结一下，假设要实现这样的一个功能：对于WEB 服务器上的特定资源，并须经过授权访问，那么我们可以截取对于该主机所有的HTTP请求，并获取请求的文件，再通过查询角色权限或者文件权限数据库，如果授权通过则返回文件，否则返回拒绝请求信息。
以上是关于WEB系统访问控制的一些思考，还没有动手检验其正确性。不过即使如果要实现这样的一个需求，也可以顺着这种思路的方向做下去。