Almost every introductory J2EE book I've ever read - plus a lot of more specialized books, such as ones on JSF - illustrate how to setup security in web.xml
And THEN they go and screw it all up by following it up with a sample user-defined login process!!! 
The reason I rant so much about this is because I really, truly have never seen a user-created security system that was secure. Most of them are about as secure as a wet tissue-paper box and that includes the ones where the resident corporate geniuses designed them.
1. Can I use <f:ajax> in my login form (j_security_check)
No. "j_security_check" is not a URL. It's an identifier used by the webapp server to determine which form on a login page contains the userid and password data. Although good practice is that there shouldn't be any other forms or functions on a login screen. A user (and a webapp) can NEVER request the login page themselves, only the webapp server can do that and it does it automatically when it determines a login is required.
2. Should I register with some special form as for login j_security_check
You cannot register a "special form" for j_security_check. The only forms that work this way are the login and loginfail pages defined in the webapp's web.xml.
3. Now I'll use only jsf components but how to render with jsf this:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
I don't understand this question, but the login and loginfail pages cannot use JSF because JSF is handled in the webapp and the login pages are handled by the server.
You must distinguish between the
resource and the
URL. Resources are the "files" that are used to resolve URL requests. Clients have no direct access to resources. Clients make URL requests. What's dangerous about this is that in many cases, the default is that if you type in a resource path as a URL, the webapp's default behavior is to copy the resource back to the client. To avoid this, define a URL
pattern to prohibit servicing URLs that look like resource paths. For example, block all ".xhtml" URLs, since they should never be directly referenced. Note that since it's URLs that are blocked and in JSF, URLs don't always match the resources being used, you need to use the "redirect" option when navigating to secured resources URLs.
That won't work in J2EE because the only time "j_username" and "j_password" have any special attributes are when they appear on a login/loginfail page being presented by the server.
In JEE an "authenticate()" method was added so that apps could run authentication without the server taking over. It won't work in older servers such as Tomcat6 or WAS 6.x. You don't need to name the userid and password fields "j_username" or "j_password", however, since the application logic is doing the work, and can therefore obtain (or synthesise) credentials from anywhere, not just "magic" form fields.
you should be very careful if you use the "authenticate" method, however, since the extra flexibility makes it possible to code logic where stuff that should only happen in a secured environment is executed
before the user was authenticated. You also need to only do this on encrypted pages, since the danger exists of sending down security credentials in a form easily displayed on a network sniffer. For best results, if you put a login option on application pages, it should be managed by its own form and not be part of the form that does the page logic and display.
utputStylesheet library="css" name="LogRegisterCSS.css" />
