-
15. Re: classic
danielsmolenaars Sep 27, 2004 11:14 PM (in response to jkuhn)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.
-
16. Re: classic
darknight Sep 28, 2004 10:59 AM (in response to jkuhn)"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)?
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? -
17. Re: classic
websel Oct 14, 2004 3:03 AM (in response to jkuhn)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");
}
}
} -
18. Re: classic
nlmarco Mar 24, 2005 8:13 PM (in response to jkuhn)"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?
We had exactly the same problem and wrote an Interceptor + special InitialContextFactory for that: http://wiki.nightlabs.de/en/Library:NightLabsCascadedAuthenticationJBoss
Not nice, but working fine. -
19. Re: classic
nlmarco Mar 24, 2005 8:18 PM (in response to jkuhn)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.
-
20. Re: classic
svandenbussche Apr 11, 2005 8:41 AM (in response to jkuhn)"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>
Using JBAS 4.0.1sp1
Just for the record, that also solves the problem for those of us who were getting an "anonymous" Principal from the SessionContext (EJBContext).
The Principal and Credential were just not propagated between the servlet container and the EJB container when using the standard JNDI InitialContext setup such as:... properties.put(Context.SECURITY_PRINCIPAL, principal); properties.put(Context.SECURITY_CREDENTIALS, credential); ...
When adding the org.jboss.security.ClientLoginModule after our custom login module, the Principal and Credential are properly propagated.
I find this, once again, a typical JBoss way of doing things, quit disturbing however, as I found nowhere reference to this in the JBoss docs (and I wonder if the J2EE specs are really OK with this, but I didn't find anything so far that said they were not).
Cheers,
---
"Optimists are just misinformed pessimists." -
21. Re: classic
starksm64 Apr 11, 2005 9:26 AM (in response to jkuhn)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.
-
22. Re: classic
svandenbussche Jun 9, 2005 5:32 AM (in response to jkuhn)"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.
I didn't say it wasn't.
however, many large projects use JBoss only for development and Websphere or Weblogic for production, so application portability between app servers is key. Security propagation between containers through JNDI has become a de facto standard.
This "feature" is simply missing in JBoss.
As for JAAS being the best solution for doing Ejb authorization, that's just a question of point of view.
Regards, -
24. Re: classic
paper Feb 24, 2006 9:35 AM (in response to jkuhn)is there a possibility to define the usage of the JndiLoginInitialContextFactory in the ear?
didn't find anything. Thanks for any help.
Dennis -
25. Re: classic
starksm64 Feb 24, 2006 3:52 PM (in response to jkuhn)No, you just use it if there is no existing security context.