用户总是关联着系统的权限规则，因此对于不同的应用来说，不可能存在一套通用的用户身份认证机制。
不论是App的用户系统还是使用声明性安全管理，对于特定的系统来说总会有一些限制，或者不能满足你的权限要求。
简单的登录或许可以，但加上权限设定，应该是只能自己做了。
所以，现实一点，考虑怎么设计用户和权限系统，减少与整个系统、应用的耦合才是出路。
使用容器提供的LoginModule就可以将数据库中的资料和容器联系起来。
to banq:
能不能对容器的LogingModule详细的进行一下说明？
谢谢！
把应用系统的权限管理和appserver的安全机制统一起来, 就好象用数据库或操作平台的用户权限管理机制来管理应用系统的用户权限一样. 技术上可实现, 但导致了系统管理的复杂和平台依赖. 没有意义.
我还是要说，请关注一下Servlet2.3引入的Filter和Core J2EE pattern中的Filter相关的设计模式。
如果一个问题可以使用设计上的巧妙或者基本API中的技术来解决，考虑别的东西都如楼上的兄弟所说，没有意义，而且入了歧途。
用Filter Servlet似乎是一个好的解决办法。因此，我们在某个项目中很高兴的采用了它。利用Filter Servlet的功能，似乎系统权限的认证交给Filter Servlet就可以解决了，不用在其它地方，包括control Servlet作权限检察.....系统结构非常的清晰，非常的干净。
在详细设计的模拟实验时时，用户登陆后，Filter Servlet的权限模块正常工作。但是，用户切换使用另一个模块时，问题就发生了：Filter Servlet无法访问特定用户的Session，也就无法取得Session中用户的资料，进而无法完成权限认证......问题就在于Filter Servlet无法访问特定的Session，这似乎也很正常，Filter Servlet监控很多的URL，因此无法绑定到特点的Session。这样一来，将用户资料放在Session就不可用了。最后，我们使用一种比较讨厌的方式，完成了Filter Servlet权限认证系统。但是，事后来看，使用老式的control Servlet权限认证方式，还要比Filter Servlet权限认证方式好的多。Filter Servlet带来的好处，还不如不能访问特定的Session的坏处大。
我承认，我们并没有深入研究Filter Servlet，上面的用法可能有误。因此，希望楼上推崇Filter Servlet的兄弟，给一个合适的解决方法，使Filter Servlet的权限模块比control Servlet的权限模块，更为好用。
TO: relive
你可以尝试自己做 Session 啊~~ 做一个 Global 的 Session, 这样无论用户在哪，它的 Session 都只有一个了 Filter 可以与 Global Session 通讯就可以了
使用容器提供的或自己编制LoginModule 是标准的J2EE安全机制，根本无需自己编制任何有关权限验证等方面的代码，这属于J2EE Web安全标准的一部分，可以参阅这个标准看看。
自己做ServletFilter有限制，如Jsp直接调用Jsp，filter就失效了，只能适合自己的特定应用。
TO iceant:
Global Seesion 应该是一个好的解决方法。谢谢您的提醒。
不过，Global Seesion 实现起来并不简单，作为SSO的一部分，它会很有用，在一些希望简单设计的项目中就似乎复杂了一些。
毕竟，对于实现了MVC架构的系统，要作权限检察时，本来就只要在C的每个流向的控制中加入一行程序，调用一个方法即可。这种实现方式，很简单，系统结构也不错。
使用Filter Server时，能不能有比上述方法更简单的权限检察实现呢。作为新规范，声明提供了解决权限问题的最好方案，应该会有更好的表现吧。
（仔细想想，也许是我的期望值过高了。:）......或者是，期望的方向不是它们要重点解决的问题。易用性，也许从来不是java规范制度者的重点考虑的问题）
在(OReilly)_Programming_Jakarta_Struts中的一个章节，专门讲了对struts的扩展，他提到：可以对RequestProcessor的processPreprocess()进行重载……一个可以替代的方法是filter，但是filter的一个缺点是他过滤得太早了，以至于无法方便的访问许多struts API……
但是，用户切换使用另一个模块时，问题就发生了：Filter Servlet无法访问特定用户的Session，也就无法取得Session中用户的资料，进而无法完成权限认证......问题就在于Filter Servlet无法访问特定的Session，这似乎也很正常，Filter Servlet监控很多的URL，因此无法绑定到特点的Session。
relive兄，在下不太理解你所说的这一段。“监控多少URL”和访问“特定的Session”有什么关系？Filter Servlet为什么要绑定特定的Session ，你所说的这个“绑定”究竟代表什么意思呢？
愿闻其祥。
同意banq的说法。
虽然我本人也是很喜欢Filter，它的功能也很强大，但是既然J2EE标准提供了很好的功能，为什么不使用呢？
我们在使用声明性安全时大部分的配置都是在标准的Web.xml文件中进行的，容器相关的配置只有将系统中的逻辑角色映射到Server的实际的角色者一步，当需要换服务器时，改动也是很小的。
TO mellon 兄：
Filter Servlet中可以访问的request是ServletRequest，而不是普通Servlet中提供的HttpServletRequest，接口ServletRequest是HttpServletRequest的Superinterfaces，有一些HttpServletRequest中的特性，ServletRequest是不支持的。很不幸，Session就是其中之一。因此，在Filter Servlet是不能访问Httpsession的（至少，不能很容易的访问到）。
用户登陆后，将用户资料放在HttpSession中，是解决权限判断时的所需资料的一个最简单的办法。采用Filter Servlet后，这个办法就不合适了。当然，你可以用很多方法解决这个问题。iceant 兄提及的Global Session 即是其中一种方法。但对于登陆要求不高的系统，实现代价就有点高了。因此，Filter Servlet引入便利的同时，带来了新的麻烦，并且麻烦程度似乎要超过便利。
以上即是“Filter Servlet为什么要绑定特定的Session”的解答。
至于“监控所有URL”以致不能访问“特定的Session”，纯粹是因为Filter Servlet采用“接口ServletRequest”这一事实，而作的猜测，并没有什么根据。只是个人觉得Filter Servlet要访问特定的Session，有些实现上的问题。
哈哈哈。
原来如此，我着实吃惊不小。
关于此，的确是有问题，不过你可以造型啊，将其造型成HttpServletRequest就行了，如果担心造型安全问题，可以使用instanceof判断在前。
Sun的推荐资料，Core J2EE Pattern中就是这么使用的，另外，你完全可以在Filter上继承一下，做一个HttpFilter嘛，然后继承之，不就可以了吗？
上溯和造型一般我们使用上溯而不是造型，因为上溯是安全的，而造型是不安全的，你必须确信其类型是符合的。但是，Sun都是这么用的，没办法了。
TO mellon 兄：
原来如此。造型或HttpFilter都应该是比较好的解决方法。实现比较简单。
我们原来完全没有动过类似的念头，可能是发现Filter Servlet中提供的仅是ServletRequest，而不是它的子接口HttpServletRequest以后，潜意识中就认为Filter Servlet使用HttpSession不安全。通常情况下，这种担心是对的，子接口实现的功能，父接口不一定支持。不过，Core J2EE Pattern也这么干了，Filter Servlet提供的ServletRequest，应该能被安全的造型为HttpServletRequest吧。
我们的解决思路只是局限于造一个Filter Servlet能访问的Session或是全局Session上，实现方法都比较麻烦。既然Filter Servlet支持HttpSession，事情就好办多了。
不过，既然Filter Servlet支持HttpServletRequest，sun干吗不实现HttpFilter呢。filter用在使用Http协议系统的情况，比其它应用都广的多。看来，Servlet2.3版这个final的称号，也许应该改动一下。