Thorsten Lamby wrote:IMHO you should be careful by deviating from server security implementation, although it sometimes may be tempting to give you an example, in J2EE you can use the web server security provided by any compliant JSP/Servlet container, this is reflected in the web.xml and in the JSPs (j_security_check) in you WAR. But this implementation does not allow any callbacks into the j_security_check action and that may be an issue if you eg. would like to setup some default context after a user succesfully logs in (<filters> do not work on j_security_check) [note: some claim this to be a flaw in the specs, others say it is a app. server bug] in my exerience though, the provided framework (eg. JAAS) typically is enough to get the job done... don't forget you're dealing with security here, implementing it yourself would surely introduce holes... and unless that's acceptable you should think twice before going on that path. another POV is: is security part of the business of your application ? if not, don't go for it... after all, you're not writing your proprietary database neither are you ? furthermore, using the server security you'll get much for free as your user and his roles are known in every part of the application, EJBs for example are designed with this in mind; as a result you can work with the java.security.Principal, that means you are guaranteed to handle an authenticated user (unless you configure your app for unauthenticated identities of course, which is not that uncommon). Because you can be sure, when you implement security yourself, you'll pass 'String userName' around your app. before you know it :-) and that's inherently unsafe. just my Wouter. |
<<inline: 2centsmall.jpg>>
