Problems with single sign-on

I can’t get a single sign-on program (SSOWatch by Evidian) to work on my login page with IE7. The SSO program is able to fill the username and password field (the text appears on screen) but they are not actually sent when the login button is clicked.

Here is a simple test case:

import com.itmill.toolkit.Application;
import com.itmill.toolkit.ui.Button;
import com.itmill.toolkit.ui.Label;
import com.itmill.toolkit.ui.OrderedLayout;
import com.itmill.toolkit.ui.TextField;
import com.itmill.toolkit.ui.Window;
import com.itmill.toolkit.ui.Button.ClickEvent;
import com.itmill.toolkit.ui.Button.ClickListener;

public class SignOn extends Application {

	private Window main;
	private TextField field;

	public void init() {
		main = new Window("Sign-on test");
		main.setLayout(new OrderedLayout(OrderedLayout.ORIENTATION_VERTICAL));
		field = new TextField(
				"Type something and click OK to make it appear below");
		Button ok = new Button("ok", new OkListener());

	private class OkListener implements ClickListener {
		public void buttonClick(ClickEvent arg0) {
			Label label = new Label("You typed: " + field.getValue().toString());

The above code generates a page with a textfield and a button. When the button is clicked, it prints out the contents of the textfield as a new label on the page.

Of course the above application works fine when I use it normally. However, when I use the SSO through IE7, the text printed below is always empty. On Firefox it works, though.

Does anyone have an idea why this happens and how to fix it?

I think the LoginForm component is the solution for you.


I have no idea how your single sign on program is working so I’m just guessing. Does it use some JS to fill fields on screen? I guess textfields onchange event doesn’t fire and Toolkit’s client side can’t detect it properly. If you can, you might try fire onchange event on the textfield some how.

As our mysterious “anonymous” forum user (not me this time) said, using LoginForm might also help you as it is based on traditional html form. It may also make it even worse as the actual form is in an iframe. Don’t remember if it is in current 5.2 release, but it can be copied from trunk as it is.


Unfortunately I don’t know how the SSO program works either. Firing the onchange event is a good idea but the program doesn’t seem to have that option. Actually, if I just make it fill the fields and not click the login, I can edit the input manually and they are still empty when sent to the server. Weird, huh?

I will try to use LoginForm. I’m wondering though if anyone has had similar experiences with testing tools for example.

That was me on the previous post. I forgot to login.

I found a solution to the problem myself. I created a script in the SSO program that works a bit differently from before. I guess the old script tried to input the values to the HTML DOM elements or something. The new and working script clicks on the field, inputs some text on to the focused window (just as if a keyboard was used) and then clicks “ok”.

It’s so simple it’s kind of funny :lol:

Hi guys,

I am completely new to Vaadin and Single sign-on (and nobody around to help),
however was asked to create a quick prototype
which would use both.

Could you please share the source code
of your fixed problem,
so I can use it as a starting up.

We are trying to implement a single sigh-on
for a bunch of web apps (incl. one with Vaadin),
which should be able to run on any app server (and Windows/Unix/Linux),
but JBoss and Tomcat would be prefered.

Please help !


At its core, Vaadin is just a Java web app using servlets. There’s nothing specific in Vaadin that helps/prevents SSO (*). I’d suggest you get SSO working first with two simple “Hello world” style web apps, and then try adding a real application like your Vaadin app.

With many application servers, there is an option to allow SSO across applications that are deployed. (In GlassFish, it’s an option at the Http service level.) Then you can use the same security realm with each of the applications and it should “just work.” If you want federated SSO across multiple application servers, then things get more complicated.


(*) Though with a web framework like Vaadin, you actually have more ways you can log in a user. I have a blog on the subject if you’re interested, but it’s orthogonal to how SSO is implemented.