I usually hesitate to speak for others but I will try to restate what I think Ron is saying and what I think r_sudh is trying to do, because I think they are different in a subtle but important way.
I think Ron interpreted the situation this way: The EJB authentication is defined to use the non-default realm X. The client is trying to force the authentication of the username and password sent from the client to take place under a different non-default realm Y.
I interpreted the original posting from r_sudh differently. The client knows that access to the EJB is governed by the non-default realm X and is in fact passing the [b]same[/b] non-default realm name X as part of the programmatic login precisely to make sure that the authentication is attempted using realm X as specified in the EJB definition.
Again, if I understood the original post correctly, r_sudh experimented by changing the EJB's realm to the default realm and making sure that the client's programmatic login passed a username and a password that were defined in the default realm. But the client still passed the non-default realm name X as part of the programmatic login. In this case, the authentication succeeded which r_sudh found surprising because the programmatic login specified a different realm from what the descriptor specified for the EJB.
Assuming that I have understood this correctly, r_sudh sees this as a bug with client-side programmatic login because not only is the realm passed to the programmatic login ignored (which the documentation does say) but more importantly there is no way the client can comply with the authentication requirements if the configuration of the back-end resource uses a non-default realm.
Ron described how the intent is for the client to be able to use programmatic login to establish which credentials will be used to try to satisfy the server's authentication requirements.
I think part of the problem is that the implementation does not match the intent. When I looked through the code before I posted my first reply, it looked to me as if the same LoginContextDriver logic is used on the client side and the server side. ProgrammaticLogin.login invokes LoginContextDriver.login, and this latter method validates the realm name argument against the collection of loaded realms that is stored in a static collection managed by com.sun.enterprise.security.auth.realm.Realm.
This validation always fails on the client side because the realms themselves are loaded only on the server, so this collection is always empty on the client. Regardless of what realm name the client passes to programmatic login the LoginContextDriver always prepares the PasswordCredential using the default realm, ignoring the realm name passed in on the programmatic login invocation.
Conceptually, it seems that the realm name validation could and should be skipped on the client side, and the caller's realm name simply stored as supplied into the PasswordCredential just as the username and password are. Then, when the PasswordCredential is used for authentication the client-specified realm, username, and password are all used to grant or reject access to the back-end resource. If the client had invoked programmatic login with a realm different from the one the EJB requires, then access would be denied as it should be.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=245203