The standard security system is fairly coarse-grained. Using it, you can define users and assign one or more role to each user (actually, zero or more, but zero roles means that only unsecured parts of the app are accessible).
So, for example, one webapp I did has an admin role, a manager role, an employee role and an auditor role. Auditors, unlike employees can only view data, not enter/change it.
And that's all that app needed. If I wanted a fine-grained matrix I could overload that with a system containing more subtlety. That way logins would be automatically enforced (a common exploit in DIY systems is to find a way around the login
test, and the server's authenticator doesn't permit that). And you can likewise block out entire sections of an app (such as the admin functions) at the role level.
For a finer approach, I'd generally construct a session-scope object to hold the fine-grained security context. That could then be used as the authorizer for the more subtle aspects and could, for example, serve as a cache for frequently-used security rules so that an LDAP query wouldn't have to be done on every incoming request. If I was really into security, I'd probably even define some custom annotations to attach to critical action methods (such as "save" and "delete"). That would allow constructs like this:
The injected logic for the "AllowOnly" annotation would then consult with your security manager, and could access both J2EE and your own custom security services transparently. And bounce unauthorized changes (throw an exception) before the user logic was invoked.
Likewise you can use features such as AOP to do similar things.
When implementing a system like this, I don't recommend tapping into the JSF lifecycle, since that only protects the JSF parts of the webapp. Instead, I recommend something more global such as a ServletFilter. That way you also protect JSPs and non-JSF
servlets.
Note that when using the built-in security system, the userID of the current user can be found in the getRemoteUser() method of the HttpServletRequest. In JSF, I try to keep framework-dependent code and constructs out of the application logic, so I have a special JSFUtils class I create that features such functions as "JSFUtils.getUserId()" and "JSFUtils.isCallerInRole(role_name)". That also makes unit-testing easier, since I can supply a mock JSFUtils and not actually have to have a webapp server running in order to do the tests.
If a user is not logged in, the remote userId is null. Otherwise you can use the userId as a key to look up user-specific data (including security authorizations) from whatever data sources (LDAP, database, whatever) that you like.
Note that there is no "login" event using container security. Container security supports Single Signon, so the user could have logged in via some other means long before they started using your app. You can tell when a user is logged in, however, by looking at the remote userID. If a user attempts to access a secured URL, login happens automatically.
The concept of Realms means that the web application neither knows nor cares whether you are using LDAP, databases, the tomcat-users.xml file, web services or some sort of mix-and-match deal. It's all transparent to the app. That's convenient for testing, especially if you have to run hurdles to get LDAP changes applied for testing. You can test using tomcat-users.xml (MemoryRealm) and run in production using LDAPRealm. Of course, if you've created a second-stage security manager and it's reaching out for additional security information, that part would be more closely tied to specifics - unless you abstract it into a generalized interface.
Finally, if you're planning on making the application alter security rules, think twice. Managing security is usually not a core business function in most webapps. In fact, in large corporations, it's common to have an entirely separate corporate department whose sole job is to manage security and/or delegate it to selected authorized personnel. So I usually prefer to handle security management in a separate app. That way there's minimal danger of "leakage" where a non-security person can alter security. And you can have tighter restraints on the security app as a whole.
