What's the benefit of using j_security_check over self-coded login module?

Question

j_security_check makes it easy to load users from a ldap server. It saves me a USER table. It's like user-management task is separated from the system.

But the problem is, in a production system with sophisticated requirements, a lot of data is associated with user id. What I expect from the user-management is not simply login/verify the password. For example I have an USER_MEMBERSHIP table, to record what kind of membership a specific user has purchased. If the user logs by j_security_check, how can I list users belonging to a specific membership? Eventually I wound up creating another USER table in my database, and fill in user info the first time they get logged in. If I have to do this, why should I use j_security_check anyway? Why not just verify the password in my database, and cut off the complicity of form_login/ldap ?

I'm getting so confused here. Is it fair to say j_security_check is for simple systems only? Is it recommended login machinism for sophisiticated Java EE applications?

Thanks in advance.

Answer 1

J_security_check is part of Container Managed Authentication, which assumes the entire burden of ensuring users are logged in, associating them with roles, and enforcing role-based access to various parts of the application as defined by security entries in web.xml. If you don't use CMA, you are condemned to reimplement all this stuff yourself. It's possible; it's error-prone; it's repeating work that has already been done. And tested.