users@glassfish.java.net

Re: Application Client Login Questions

From: <glassfish_at_javadesktop.org>
Date: Wed, 21 May 2008 07:51:17 PDT

Hi.

Your observations about the sequence of events are correct from the developer's and user's point of view, with the one minor clarification that it is not the app client itself that performs the injection but rather the app client container (ACC).

The ACC loads the client's main class and then performs any injection required, which as you described triggers the authentication.

By the way, what release of GlassFish are you using? There was a change checked in by the security team for Issue 2310 so that the client authentication is repeated if the user enters invalid credentials. From your description it seems as if you are not seeing that behavior. Here's the issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=2310 The question of distinguishing between the user entering invalid credentials and the user choosing "cancel" was not addressed in that fix.

As for question 1, this is an interesting and tricky area. The authentication triggered by injection takes place before the app client has gained control. So there is no place for you to catch the related exception in your code, given that your code has not been called yet.

Regarding question 2, because the client has not received control before the injection-related authentication takes place the client cannot perform its own authentication before the ACC runs the injection-related authentication.

This is something we would like to improve in a later release. In the meantime, one alternative approach you could consider would be to not use injection but use explicit JNDI look-ups for the remote resources. I know this is much less convenient than using injection, but doing so would remove the injection-triggered authentication that occurs before your code is in control. Since with explicit look-ups the authentication would occur only when your logic looks up the guarded resource, you could make sure that happens within a try-catch block in your client.

Again, I realize this is far from an ideal solution. But you might want to weigh the trade-offs and decide if it's an option for you.

You might also want to file a new security issue to highlight this problem.

I'm sorry the answer is (probably) not what you were hoping to hear.

- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]

http://forums.java.net/jive/thread.jspa?messageID=275736