Briefly, I think it's a bug in the client-side security handling and we'll want the security folks to weigh in on this.
The documentation (
https://glassfish.dev.java.net/nonav/javaee5/docs/AS91DG.pdf, p. 103 at the moment) does state that the realm argument to ProgrammaticLogin.login is ignored on a client.
So the next question is, "Why?"
A visit to the source code reveals that ProgrammaticLogin.login invokes LoginContextDriver.login and passes the realm, which in turn invokes Realm.isValidRealm and passes the realm. The implementation of Realm.isValidRealm searches for the specified realm in a collection of previously instantiated realms. (A realm is instantiated by invoking Realm.instantiate, and one of its arguments is the name of the class which implements that realm.)
This logic works just fine on the server side, where the realm's implementation class is accessible and, most likely, any resources (such as a file or database used in authentication) are also accessible. Once you create your custom realm using the asadmin create-auth-realm command of the admin console, GlassFish takes care of invoking Realm.instantiate for you...on the server side.
But it does not make sense to instantiate a realm on the client side. So on the client side the collection of instantiated realms is empty, Realm.isValidRealm reports that the realm you passed to ProgrammaticLogin.login is invalid, and so LoginContextDriver.login uses the default realm.
I think this explains what you are seeing.
My thought is that the decision about whether a realm is valid or not can be made only on the server side, so the current validation that is done the same on both the client and the server should not be done - at least not that way - on the client side.
Now we need to let the security folks add in their thoughts on this.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=244969