How to handle authentication/authorization with users in a database?

Question

Currently, I am working on a web project using JSF 2.0, Tomcat 7 and MongoDB. I have a big question of how to handle the session management and authentication/authorization with users in a database.

The structure I want is as follows: only logged in users can create events and everyone can see the created events.

• create.xhtml --> only for logged in users.
• events.xhtml --> public for everyone.

The basic structure I'm planning is:

• Check if the page requires logged in user (e.g. create.xhtml)
• If yes, check if user is logged in
• If user is not logged in, go to login.xhtml
• If successfully logged in, come back to requested page
• Keep the "User is logged in" information unless user clicks log out button. (there I guess @SessionScoped gets into play)

The question is:

1. What is the less complicated way of doing this?
2. Where should I use the @SessionScoped annotation? In Create.java or LoginManager.java?
3. Spring security looks kind of complicated for my issue, do I really need it? if yes, can you explain a little bit of how the implementation works together with JSF 2.0 and Mongo DB?

Answer 1

There are several options. Which to choose is fully up to you. Just objectively weigh the concrete advantages and disadvantages conform your own situation.

---

1. Use Java EE provided container managed authentication

Just declare a <security-constraint> in web.xml which refers a security realm which is configured in servletcontainer. You can for your webapp specify URL pattern(s) which should be checked for login and/or role(s), e.g. /secured/*, /app/*, /private/*, etc.

Before Java EE 8, you unfortunately still need to configure a security realm in a servletcontainer-specific way. It's usually described in servletconainer-specific documentation. In case of Tomcat 8, that's the Realm HOW-TO. For example, a database based realm based on users/roles tables is described in section "JDBCRealm".

Since Java EE 8, there will finally be a standard API based on JSR-375.

Advantages:

• Relatively quick and easy to setup and use.
• Since Java EE 8 there's finally a robust and flexible standard API.

Disadvantages:

• Before Java EE 8, realm configuration is container-specific. In Java EE 8, the new JSR-375 Security Spec should solve that with help of JASPIC.
• Before Java EE 8, , there is no fine grained control.
• Before Java EE 8, it's very spartan; no "remember me", poor error handling, no permission based restriction.

See also:

• Performing user authentication in Java EE / JSF using j_security_check - contains complete code examples
• Java EE kickoff application - example web application (developed by me) which also demonstrates Java EE 8 authentication with Soteria (the JSR-375 RI).

---

2. Homegrow a servlet filter

This allows for much more fine grained control, but you're going to need to write all the code yourself and you should really know/understand how you should implement such a filter to avoid potential security holes. In JSF side, you could for example just put the logged-in user as a session attribute by sessionMap.put("user", user) and check in the filter if session.getAttribute("user") is not null.

Advantages:

• Fine grained control.
• Completely container independent.

Disadvantages:

• Reinvention of the wheel; new features require a lot of code.
• As starter, you're never sure if your code is 100% robust.

See also:

• Is there any easy way to preprocess and redirect GET requests? - contains introducory explanation and kickoff example for authentication
• Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same - contains more extended kickoff example for authentication which also covers ajax requests
• How control access and rights in JSF? - contains kickoff example for authorization

---

3. Adapt a 3rd party framework

For example, Apache Shiro, Spring Security, etc. This offers usually much more fine grained configuration options than standard container managed authentication and you don't need to write any code for this yourself, expect of the login page and some (XML) configuration of course.

Advantages:

• Fine grained control.
• Completely container independent.
• No reinvention of the wheel; minimum of own code.
• Thoroughly developed and tested by lot of users, so most likely 100% robust.

Disadvantages:

• Some learning curve.

See also:

• JSF2 - Shiro tutorial - an extensive tutorial on integrating Shiro in JSF2 webapp