Custom Java form login Filter vs 'blackbox' approach (JAAS, j_security_check, etc)

[Kevin P Smith]

OK, this is more an general enquiry than anything...

This isn't fully working code; in fact it was written quickly so is more pseudo code than real code.

I'm just wondering, from a 'stupidly simple' user login point-of-view; what do JAAS, j_security_checker, Shiro etc do
which this doesn't (excluding Realms for now, will look at that later.)?
Why would (if at all) this be an unsecure (ineffective) method of simply checking a user's username/password and allowing them
to a secure page if authenticated, else redirecting them to the login screen. By that I mean is there a way you could do XYZ and always be authenticated.


The URL

http://localhost/myApp/secure/mySecurePage.jsp

web.xml

<filter>
	<filter-name>stupidlySimpleLoginFilter</filter-name>
	<filter-class>.../StupidlySimpleLoginFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>stupidlySimpleLoginFilter</filter-name>
  	<url-pattern>/secure/*</url-pattern>
</filter-mapping>

Example Filter

public class StupidlySimpleLoginFilter {

	private FilterConfig filterConfig;
	
    public void doFilter(ServletRequest req, ServletResponse res,
            FilterChain chain) throws IOException, ServletException {
 		
		boolean isAuthenticated = false;

        HttpServletRequest request = (HttpServletRequest) req;
		String username = request.getParameter("usr_username");						
		
		if (username != null) {
			User user = new User();
			user.setUserName(username);
			username = null; // trashed!

			StupidlySimpleLoginJdbcLookUp loginJdbcLookUp = new StupidlySimpleLoginJdbcLookUp();
			User user2 = loginJdbcLookUp.findUser(user);
			user = null; // trashed!

			if (user2 != null) {

				String password = request.getParameter("usr_password");
				if (password != null) {
					StupidlySimpleMessageDigester msgDigst = new StupidlySimpleMessageDigester();
					String encryptedPassword = msgDigest.digestSHA512(user2.getSalt(),password);
					password = null; // trashed!
					
					if (user2.getPassword().equals(encryptedPassword)) {
						isAuthenticated = true;
						
						HttpSession session = request.getSession();
						session.setAttribute("isAuthenticated", isAuthenticated );

						encryptedPassword = null; // trashed!
						user2 = null; // trashed!					
					}
				}
			}
		}
		
		if (isAuthenticated) {
			chain.doFilter(req, res);
		} else {
			filterConfig.getServletContext().getRequestDispatcher("./stupidlySimpleLogin.jsp");
		}
	}
	
	public void init(FilterConfig filterConfig) throws ServletException {
		this.filterConfig = filterConfig;
	}
	//...
}

Cheers in advance

[Ulf Dittmer]

A topic dear to my heart :-)

For starters, it's important to remember that the various security solutions you mention have somewhat differing purposes and capabilities.

yours: authenticate users of a web app

j_security_check a.k.a servlet security: authenticate and authorize (A&A henceforth) users of a web app. Authorization means each users can have different roles assigned, although that's used much less in web apps than the authentication part.

JAAS: a general A&A solution for Java. It can tie into servlet security (witness Tomcat's JAASRealm), but is not a really good fit; see Using JAAS in Java EE and SOA Environments for some more information on that. It's more commonly used in desktop apps and app servers than in servlet containers. It has a lot of extension points, so it can be made to work with just about any A&A approach, including hardware devices and non-Java processes.

Shiro: a library that implements a lot of functionality you'd need for A&A in all Java environments (not just for servlets), but also cryptography and session handling (also independent of servlets). This is what I would use for just about any new project, or any project where security needs to be substantially reimplemented.

Why would you use any of these over yours? Because, with all due respect to your coding ability, security is very hard to get right, and very easy to implement in a way that leaves your system open to attacks. It's much better to use something tried and tested, not to mention the savings in development time.

[Kevin P Smith]

Hi Ulf,

Yes I noticed you replied to my post a few weeks back about JAAS and if it was worth the effort.

I think j_security_check would be the closest fi to what I'm looking for (basically a simple login, but with some 'roles' witin the the admin side of things).

There are although, a couple of issues I have with j_security_check.

1:
Plain text! Now maybe this isn't an issue at all, but I have always encrypted (MessageDigest) passwords. I can't see a way to do this with j_security_check, in fact it seems to work with clear text passwords.

2:
Going straight to a login page. j_security_checker is great for attempting to access a secure page, but if the user goes to a login form?


NOTE:
Actually on point 2, I suppose my 'login' link could try to take the user to their 'homepage', then it would goto the login screen first and then redirect to the 'homepage'.

[Ulf Dittmer]

Kevin P Smith wrote:1: Plain text! Now maybe this isn't an issue at all, but I have always encrypted (MessageDigest) passwords. I can't see a way to do this with j_security_check, in fact it seems to work with clear text passwords.

There are two parts to this: encryption in transport (i.e., using DIGEST auth instead of BASIC auth) and encryption in storage (storing digested passwords in the DB or wherever instead of cleartext passwords). The mechanics will differ between servlet containers, but for Tomcat both are discussed in http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#Digested_Passwords

Going straight to a login page. j_security_checker is great for attempting to access a secure page, but if the user goes to a login form?

That's not how servlet security is meant to work - the login page is only used en route to a protected page, not as an entry page itself. So there should not be a link to it anywhere. I'm not sure what happens if a user goes there directly - he may be redirected to the home page after login.

[Kevin P Smith]

You've touched on point 2 with this person too.

https://coderanch.com/t/441617/Servlets/java/security-check-login

I think if you go directly to the login page and login, you get redirected to.... the login page! :-)

So I thought maybe my login link could actually try to take the user to their ./secure/homepage page, that would sort of work around it.