There's nothing JSF specific to this. If you are using
JEE's standard security framework (supplied with WebLogic), everything is done by WebLogic. You have to configure a security Realm in the WebLogic server, bind it to the webapp(s) that will be secured by it, and include the certificate information in the WebLogic secure transport configuration. So it's mostly questions you need to ask in the WebLogic forum - although WebLogic was pretty good in documenting those processes.
When using container-managed security with form-based login, you design a basic HTML or
JSP login form in 2 almost-identical parts. The login form is the page that WebLogic (
NOT the webapp!) will present when a user makes a request to a secured URL as mapped in the webapp's web.xml file and the user is not already logged in. If the login fails, then WebLogic will present the loginfail page repeatedly until the user either logs in or gives up and goes away. My loginfail page usually is a clone of the login page, but with the added caption "Login Failed!".
There is no application login code and the application does not get notified when the user logs in (this may have been done in some other app in the webapp's security Realm or via Single Signon, Windows Login, or some other place remote in time and logic). You can always tell when you are logged in, however, since the HttpServletRequest getUserPrincipal() and getRemoteUser() methods return null until the user has logged in. The getRemoteUser() method returns the userID, which is also stored in the UserPrincipal object. Because the code to get the userID (and to
test user security role authorization) is particularly ugly in JSF, I keep a separate utility class to hold it. That allows me to use simpler, more abstract code in the application logic itself. It also allows me to swap in a testing security module for offline (unit) testing.
JEE container security is primarily about limiting access to secured URLs. If the user fails in authentication or authorization, the user never even gets to application logic and therefore cannot exploit it. So actual security code within the webapp is usually minimal.