Afair ja.
Also generell hab ich das Gefühl, dass du noch sehr viele Verständnisprobleme hast. JavaEE ist da imho auch recht wenig Einsteigerfreundlich. Deswegen mein erster Rat: wenn dich der Bereich interessiert, dann wäre der Start mit Sprint Boot sicherlich ein angenehmerer (eine Sache mit der ich mich gerade sehr Stark im Betrieb und privat beschäftige).
Aber mal ungeachtet dessen sollte das Nachfolgende abstrakt genug sein, dass es für beides funktioniert:
Du musst dir klar machen, welche Rollen deine Klassen haben. Dann wird dir auch recht schnell klar werden, dass eine Model klasse keinen Scope definieren muss.
Wenn ich das ganze Gliedern müsste, dann käme jetzt erstmal sowas bei raus:
Controller
Arbeitet zusammen mit deinem Template (JSF). Da er die Daten verarbeitet/beschafft besitzt er einen Scope (request, session, whatever). Ums mal anders zu sagen: der Controller kann Statefull sein.
Model-Klasse
Wäre hier jetzt dein User. Annotation die hier ok wären, wären z.B. JPA-Annotation wenn du ein orm verwendest. Es dient rein zur Datenhaltung und ist nicht an irgendwelche Scopes gebunden.
Trivia: Oftmals ist es sogar so, dass man solche Klassen in ein extra-Projekt auslagern kann und als api nutzt. Wenn du diese z.B. in einem Android-Projekt verwenden wolltest, dann müsstest du in dem Android-Projekt auch die JavaEE-Annotationen drin haben. Das ist ein gutes Beispiel dafür, warum Klassen definierte Aufgaben haben sollte.
Service-Klasse für Login
Wie der Login abläuft hat im Controller nichts zu suchen. Stell dir vor, du wolltest die gleiche Logik an anderer Stelle verwenden. Stell dir einfach vor, du würdest noch einen Controller für einen RESTService und WebSockets anbieten. Dann dürftest du das ganze 3x neu schreiben. Also packst du was mit dem User zusammen hängt in einen user-Service. Diesen könntest du dann im Controller verwenden.
Optional: Gateway
In meinen (kleineren) Projekten haben die Controller doch recht viel logik mit sich gebracht, die ich aber an anderer Stelle (RestController, …) exakt genauso gebraucht hab. Dafür hab ich dann Gateways welche dann praktisch nur noch als Delegate von den Controllern verwendet wurden. (Kennt keinen Scope/Stateless)
Trivia: Ein Gateway ist ähnlich der Facade. Unterschied: Facade verbirgt was nach außen hin, ein Gateway etwas nach innen.
Zusammenfassend hat man dann nur den Controller welcher SessionScoped sein kann. Er kann dann den User (welchen er vom Service bekommt) einfach in einem Feld vorhalten und dadurch brauchst du den nicht jedes mal neu anzufragen.