how to let Java login tomcat form authorization

[reubin haz]

I have built a JSP web app program, which uses Tomcat FORM authorization. Now I want to create a servlet that automatically login to the web app, which means instead of a user open the login page, fill in user name and password, I want to Java to call something to login, and then forward user to the page inside, so the user has no need to go through the login page.

So far I created some sessions and use dispatch to forward user to a page inside. That page can be displayed but any links or buttons inside will trigger Tomcat to redirect user to login page again, because Principal, realm/roles of tomcat is not set yet. But how do I set them? Or what's the way to bypass tomcat security check? Or how to let Java to pass user name and password to tomcat so principal, roles can be set up?

Thanks.

[Tim Holloway]

There isn't anything called "Tomcat FORM authorization". Form-based authentication is part of the J2EE standard spec, and is required to operate in a certain way, regardless of whether your server runs Tomcat, WebLogic, or OC4J.

The system itself is known as "container-based authentication and authorization" (or container-managed A&A), and you don't program login handling or redirection code into it. In fact, the login process is so transparent that the app is never notified when a user logs in. URLs which are guarded by the security system simply cannot be accessed until the user has validated against the container.

The whole process is effective and well-defined, but because it's also fairly sophisticated, I recommend you get a good book or 2 on J2EE.

[Ulf Dittmer]

instead of a user open the login page, fill in user name and password, I want to Java to call something to login, and then forward user to the page inside, so the user has no need to go through the login page.

What's the point of having security in the first place if you want to circumvent it?

[reubin haz]

Ulf Dittmer wrote:

instead of a user open the login page, fill in user name and password, I want to Java to call something to login, and then forward user to the page inside, so the user has no need to go through the login page.

What's the point of having security in the first place if you want to circumvent it?

The point is to let an external client who has signed on their own system, giving them the access to my web app without login again, through a servlet, that decrypt some user info and then use my web app right away.

If 'the login process is so transparent', so I cannot modify it at all? Then how to deal with my situation?

Thanks.

[Tim Holloway]

reubin haz wrote:

If 'the login process is so transparent', so I cannot modify it at all? Then how to deal with my situation?

Thanks.

Actually, because it's so transparent, you're in better shape than if you did your own security code. What you're describing is essentially Single Signon (SSO), and Tomcat has several options for that.

The operative word here is "Realm". A Security Realm defines the scope and rules for authentication and authorization. If you use an SSO realm, signing on to any participant in that realm grants you access to all other participants without the need to sign on again. And therefore, the need to present a signon screen. Or to not present one. As I said (I think!) the actual login (and loginfail) pages are presented by the webapp container (Tomcat) when the need for form-based validation is detected. If the realm detects you're already signed in, the login page won't be presented.

[reubin haz]

Yeh, you are right. I'm implementing single sign on. I mentioned 'Realm' in my first post. But I don't know how to set up its value, or how to configure tomcat.

Could you please give more info on how to setup this in tomcat 5? Thanks.

[Ulf Dittmer]

Searching for "sso tomcat" will take you right to the relevant part of the Tomcat documentation.

[reubin haz]

I did some readings on the internet. It seems tomcat sso is used on a set of web applications deployed on *a particular virtual host*
So I guess it's working for different web app on a single tomcat server. But my situation is about let a user from some other server that I don't know what type of server it will be. Would it still work? Or the external client has to come from a *tomcat* server first and configured properly?

Thanks

[Tim Holloway]

It's quite common for a site-wide SSO implementation to be used. In cases like this, the actual authentication and authorization is typically done by a single security server (which doesn't have to be running Java). Tomcat simply subscribes to that server. Other J2EE servers - whether on the same box or halfway around the world would do likewise.

If you have a server running something other than J2EE, such as Microsoft's IIS, it, too can participate as long as it also has a security feature that works with the SSO server. In other words, something that performs the same basic functions that a Tomcat Realm does, except that it does them for Microsoft webapps.

SSO isn't something for just one server, one language, or one OS. If it really expects to live up to its name, it has to be able to handle all the apps in all the servers, wherever and whatever they are.

[Ulf Dittmer]

Several different open source java implementations of SSO can be found at http://faq.javaranch.com/java/SecurityFaq#web-apps

[reubin haz]

I read an article from http://docs.huihoo.com/apache/apachecon/eu2007/AnilSaldhana_UnderstandingTomcatSecurity.pdf
which talks about writing customized Valve and Realm implementation and then configure them inside META-INF/context.xml. But the problem is I also want to have the existing realm implementation, login page to be working at the same time, which is already configured in META-INF/context.xml

I don't know where to put the 2nd set of customized configuration, since there is only one context.xml can be existed and only one <Realm> and <Valve> can be specified. Please help.

[Tim Holloway]

Hmmm. That's in interesting document. Valves haven't gotten as much coverage as they deserve.

However, that's also straying a bit much from standard J2EE, and I don't think you need anything that ambitious. I'd recommend looking at Ulf's list of providers, selecting the most appropriate one, and reading what its requirements are. If it requires a special Valve, OK, but otherwise, just worry about the Realm.

You only need to implement custom realm/valve code if none of the ones that people have already written/debugged will do what you need. I did one recently because for some silly reason the standard JDBC Realm doesn't support case-insensitive userIDs, and that's a requirement, so I extended the existing realm. And I've written Realms for specialized web-service based authenticators. But mostly I prefer to use the ready-out-of-the-box ones.

The stock Realms are designed to implement Form-based Authentication per the J2EE standard. That means that if (and only if), they detect that you're attempting to use a guarded resource and you haven't authenticated within the realm, THEN they'll retrieve the login page that you designated in that webapp's web.xml file and use it to capture userid/password for authentication.

Normally I don't have a site-wide login page, so that's fine with me. At worst, I just include a basic generic 2-field+button form. Sometimes I put the application's logo on the login page, just to reassure the user.

When you authenticate against an SSO domain, you're not just doing it on a per-server basis. If you logged in ANYWHERE in that domain, then an SSO Realm will check with "Security Central' (the SSO server). Only if that central server says you're not already logged in will the Tomcat SSO Realm instruct Tomcat to iniitiate the login process (display the login page and authenticate against it). If the user successfully logs in, the Tomcat SSO Realm will set up the needed internal security objects and also notify Security Central that the user is now logged in. So that no other app will present an unnecessary login screen, either.

[Pat Gonzalez]

> The point is to let an external client who has signed on their own system,
> giving them the access to my web app without login again

I think in the Kerberos land this is known as having a trust relationship between the two domains/realms.

http://www.kerberos.org/software/tutorial.html (see section 3.1)

An example in MS Active Directory...

http://technet.microsoft.com/en-us/library/cc775736(WS.10).aspx

Good luck!