JBossDeveloper

The only way I managed to do it, was using the POST="j_security_check" of my login.jsp FORM. I didn´t really like the solution, but I couldn´t find anything else.

"tthiele" wrote:
The ClientLoginModule places the principals and credentials which are aquired by the previous login module(s) in a magic way to a magic place where bean invocation mechanism passes them to the container resp. beans. I suppose the security information is associated with the Thread object. But I don't know the details. Can someone give a pointer to the documentation (not the java sources)?

There's a little err in the callback class, this one is compiling


public void handle(Callback[] callbacks)
throws java.io.IOException, UnsupportedCallbackException {
for (int i = 0; i < callbacks.length; i++) {
if (callbacks instanceof NameCallback){
NameCallback nc = (NameCallback)callbacks ;
nc.setName(username);
} else if (callbacks instanceof PasswordCallback) {
PasswordCallback pc = (PasswordCallback)callbacks ;
pc.setPassword(password);
} else {
throw new UnsupportedCallbackException(callbacks , "Unrecognized Callback");
}
}
}

"Darknight" wrote:
Very interesting, but then if I have a multi threaded swing application (I do) how do I propagate that magical stuff? I have to call the server ejbs in a number of places and it's quite ugly to programmatically auth the user on every call.
I'm sure I'm not the only one using ejb/jaas this way. Has anyone found a solution?

Well, not exactly the same problem, but very similar (cascaded authentication within a server) and I think that you could use this solution in the client as well. It simply "sticks" the authentication information to the connection (your bean handle) instead of the thread. IMHO easier handling and more straight-forward when working with different servers or sharing EJB handles between different client threads.

"tthiele" wrote:
hmmm... I think there is this missing in your application-policy as the last login-module:

<login-module
code = "org.jboss.security.ClientLoginModule"
flag = "required">
</login-module>

...
properties.put(Context.SECURITY_PRINCIPAL, principal);
properties.put(Context.SECURITY_CREDENTIALS, credential);
...

There never has been any statement about using the JNDI InitialContext as the means of providing the user login info. JBoss has always used JAAS and this is in complete accord with the specs.

"scott.stark@jboss.org" wrote:
There never has been any statement about using the JNDI InitialContext as the means of providing the user login info. JBoss has always used JAAS and this is in complete accord with the specs.

http://wiki.jboss.org/wiki/Wiki.jsp?page=LoginInitialContextFactory
http://wiki.jboss.org/wiki/Wiki.jsp?page=JndiLoginInitialContextFactory

is there a possibility to define the usage of the JndiLoginInitialContextFactory in the ear?
didn't find anything. Thanks for any help.

Dennis

No, you just use it if there is no existing security context.