Tomcat auth-method = form with 3 login fields.

[Peter Wilkinson]

I'm wanting to use tomcat authentication, but I've got 3 fields I need to verify. Is it possible to do this?

I'm wanting to supply
Username/PIN/ANumberFromOneOfThoseKeyRingThings.

but the default form authentication only has username and pass.

I'm quite happy to implement my own JAAS auth module, but figured I should make sure tomcat is capable of querying it in the correct method first.

Thanks,
Peter

[Tim Holloway]

Welcome to the JavaRanch, Peter!

This isn't a Tomcat limitation, it's an architectural limitation in J2EE, which assumes that only 2 security tokens will be presented. It's actually a little surprising, since there are other systems, such as IBM's RACF that can call for a third option, and I once worked on a platform where they wanted an Active Directory domain as a third option.

It's not totally impossible. I think that there's an OpenID Realm that has similar requirements. However, the basic Realm architecture expects only gets passed a userID and credentials (password) field to its "authenticate" routine, so any addtional information would have to be dug out through alternate channels, and I don't think that the original form data is available at that point.

[Peter Wilkinson]

Hmm,
Could I stick some sort of request forwarder between my form and the jSecurityCheck?

i.e.

my form posts to a servlet I write.

The servlet combines 2 of fields into a pipe seperated value

String password = pin + "|" + pass;

Then add this as the password field for the request and forward it on?

My JAAS module could then turn it back into 2 seperate fields.

Does this sound viable?

[Tim Holloway]

Container-managed security doesn't login to the webapp. In fact, it doesn't go anywhere near the webapp, so you can't write a servlet to do that. But you might be able to write a Tomcat Valve that does it.

[Peter Wilkinson]

A valve you say. Tell me more =)

On the forwarding bit, I don't need the security to get to the web app. I want to tinker with the request a bit before it gets to security. Will the tomcat security handling thing at j_security_check really know whether it got the request from a browser or via my servlet?

[Tim Holloway]

Tomcat's security is J2EE Container-Managed security. You can't use CMSec and a do-it-yourself login at the same time. When they say container-managed, they mean it. If a URL comes in and the container (Tomcat) decides that something needs to be done, it won't even let that request NEAR any of the webapps unless it has first done whatever container security functions are required AND if it's a user URL request. j_security_check requests are eaten in their entirely by Tomcat itself and are not passed on to any application. The application, in fact doesn't even realize a login was ever done unless it happens to check its HTTPServletRequest obejct and sees that the userid and UserPrincipal objects are no longer null.

You also can't submit an unsolicited j_security_check. It has to be in reply to an actual container challenge, and container challenges are initiated when a client requests a secured URL (as mapped out in the app's web.xml file) AND Tomcat has determined that the user is not yet logged in and therefore is not yet running with approved credentials and a UserPrincipal object.

A Valve is a class that you can add to Tomcat's internal pipeline to shape, analyze and/or route requests. In your case, that would involve dissecting the inbound j_security_check form and making the data more amenable to the standard security interfaces. For more details on Valves, check the Tomcat documentation.

Definitely, however, if your security environment is stringent enough to require 3 credentials, I don't recommend inventing your own login system. Because if you actually create one that's secure enough, it will be the first DIY security system that actually was secure that I've seen in over 10 years in J2EE, and that includes sysems used by major financial institutions and even the US Government. True security isn't as easy as it looks.

[Peter Wilkinson]

So is using the standard tomcat form authentication considered insecure?

[Tim Holloway]

Peter Wilkinson wrote:So is using the standard tomcat form authentication considered insecure?

Only if you select an insecure transport. web.xml controls what security options for transport you use.

But Tomcat's form-base authentication isn't a DIY security scheme, it's J2EE standard container-managed authentication. The only thing that comes from the app is the login and loginfail page templates. No application executable code is ever employed and the application is not only unaware of the when the user has logged in (as mentioned earlier), the application isn't even aware that the page templates have been accessed.

There are other cases where the J2EE container uses web.xml to retrieve resources from a webapp without actually running webapp code as well. For example, custom error pages.

[Peter Wilkinson]

Bah, I don't see why this is so hard.

I'll just do it in javascript and the rest can go rot...

<!doctype html>
<html>
	<head>
		<title>Login</title>
		<style type="text/css">

		</style>
		<script type="text/javascript">
			function init() {
				var loginForm = document.getElementById("loginForm");
				loginForm.onsubmit = generatePassword;
			}

			function generatePassword() {
				var passwordField = document.getElementById("passwordField");
				var pinField = document.getElementById("pin");
				var passCodeField = document.getElementById("passcode");
				passwordField.value = pinField.value + "|" + passCodeField.value;
			}

			window.onload = init;
		</script>
	</head>
	<body>
		<form id="loginForm" method="POST" action="j_security_check">
			<input id="passwordField" type="hidden" name="j_password">
			<ul>
				<li><label for="j_username">UserName : </label><input type="text" id="j_username" name="j_username"></li>
				<li><label for="pin">Pin : </label><input type="text" id="pin" name="pin"></li>
				<li><label for="passcode">Pass Code : </label><input type="text" id="passcode" name="passcode"></li>
				<li><input type="submit"></li>
			</ul>
		</form>
	</body>
</html>

[Tim Holloway]

Good security is hard. One of the things that's absolutely killing the reputation of the entire software development industry is the "All You Have To Do Is" syndrome. Computers are incredibly stupid, and making them understand perfectly simple and perfectly reasonable requests (in human terms, that is) is a lot more work than users, managers, or even the programmers themselves allow for.

But I'll give you a pass on that one. There's nothing in what you're doing that's any more exploitable than more elaborate solutions of the same stripe wouldn't have.

[Peter Wilkinson]

Appreciate your input. =)