Thank you. And welcome to the JavaRanch!
When I first looked at this I thought you were using the web.xml security (container-managed security) and making a common mistake. Actually, it seems you're working with a Do-it-Yourself security system, which means that instead of being able to give advice on a well-documented standard, all I can do is recommend things to help you debug. Spend any time around the JavaRanch, and you'll hear plenty of ranting from me on why a DIY security system isn't a good thing. I have a fairly long list of reasons, but the most important one is that I've really never seen a DIY security system that was truly secure. Most of them, in fact, wouldn't hold off a real attacker for more than 5 minutes.
Nevertheless, DIY is popular, despite the expenses, both immediate and post-invasion. So here goes.
I can't see your total security infrastructure from these examples, but my suspicion lies in some basic
JSF behaviors. When a JSF View posts data (such as a login form), the default behavior is to redisplay the View. That's different from most architectures. So a DIY JSF login form would typically need a login Action method that returns a value that can be used for navigation, such as "success" (user logged in OK) and "failure" (Login failed). The faces-config file then is consulted to find the appropriate navigation rules, which are typically to go to the user's home page :success", or to redisplay the login View ("failure"). Since the default is to redisplay the current View, an explicit failure rule is optional.
Actually, I didn't see any reference to a backing bean at all in your faces-config, so there was no obvious place for the login credentials to be passed, nor definition of a login action processor. Validators and converters are part of the MVC Controller framework and don't have business logic capabilities, so they're not sufficient to process logins.