You cannot create a "login" role. Until a user is logged in (authenticated), you don't know who that user is, much less what role(s) they operate under. The closest approximation to a "login role" would be to remove the user from the credentials data or change the user's password to something the user does not know and cannot guess.
Authentication is triggered by an attempt to access a secured URL, as defined by the security URL
patterns in your app's web.xml file. Authorization is done, once the user has authentication (and ONLY IF a user has authenticated successfuly), by the server asking its Realm if any of the roles assigned to that URL pattern are present in the Realm's list of roles assigned to that user. If not, the server rejects the URL request (403 FORBIDDEN) and the application logic is never offended by the unauthorized request (and therefore cannot be exploited by it).
Just to clarify the preceding: The login/loginfail pages have no URLs. A user cannot invoke them directly (if you do, it won't function properly). ONLY Tomcat can dispatch these pages and it does so automatically when a restricted URL is requested by an un-authenticated user. That gets rid of one of the most common exploits, which is to simply jump around the login page and go directly to the secured URL. Tomcat handles login if needed and when needed and there's no application logic involved.
There are also some role API methods, such as the HttpServletRequest isUserInRole() method that can be used to restrict access to application logic based on the user's roles;
The system might seem a little awkward until you realize that it has some essential properties, which can be synopsised as "Never Volunteer Information":
1. Access to secured resources is restricted at the server level where possible (Container Managed). Which, like I said, helps prevent attackers from exploiting possible weaknesses in the application logic. The server's logic is more isolated, thus less exploitable for specific business goals and also, of course, much better tested and maintained.
2. You cannot retrieve security information, only petition it. There's no API to return the user's password or role list, only APIs to check if the user can act in a role. This prevents "fishing expeditions" that would search for a privileged user ID and exploit it. And you never, never, never can access the password. In fact, the effective SQL for authentication is "SELECT COUNT(*) FROM USER WHERE USER_ID=? AND PASSWORD=?". The actual password never leaves the database server, so exploits cannot troll Tomcat for passwords. The worst that they could do would be to snoop user-submitted passwords and see what userid/password combinations validated. And even that would require major exploitation of Tomcat's internal logic.