Every request (for a secured resource) to the JBoss server (even from the Tomcat server) needs to contain the username and password. There is no http-like session. What should happen is that the username and password is cached in JBossSX so each request is checked against the cache version versus always invoking the login process (which in your case means accessing your LDAP server.) So if you are not seeing this behavior some things to check are...
1) the cache timeout settings for your security manager
2) enable TRACE logging in JBossSX to see what the principal being check is as well as that the authentication cache contains.
3) you can also view the contents of the authentication cache for the security domain using the jmx-console (jboss.security:service=JaasSecurityManager)
hope this helps, cgriffith
thanks for that info. I have just started looking at securing things w LDAP and wasn't sure on the session thing.
Reason i'm asking is that I want a login-procedure in the client, and a timeout-behaviour like what you'd get on a webpage and an http-session. It would be great if you had a session+login w LDAP on the jboss server.
So i guess the only way is for me to have a mouselistener or something on the swing client and handle the "session timeout" myself...
Just so I can understand your environment...
Your standalone Swing client performs a JAAS login which includes your custom LDAP LoginModule then JBoss' ClientServerLoginModule.
This allows the user to be authenticated/authorized to your client, as well as have the username and password propogated to JBoss server on calls in the same thread. How are your
calls made against the serverauthenticated? To be more specific, what login modules do you have configured for those calls (i.e. that security domain)?
yeah, you got it right, user basically gets a popup window, app first authenticates directly against our LDAP, then uses jboss clientloginmodule to put params in, which then are used when client app uses EJB's on the jboss server. EJB's are setup so that access is secured through LDAP, i.e. the jboss server then makes the authentication to the same LDAP server, with the credentials provided in the EJB call. Hope that explained it... :)
So, since i wasn't 100% in the loop on how the LDAP protocol worked, i had hoped on some handle/session ID that would be sent back and forth after the "initial LDAP login" against the jboss server which then would be cached, session like, but that apparently is not how it works, unfortunately.
If you have any other idea, I'm all ears!
Just to make things more clear...
Your swing client will authenticate/authorize user to use the client. At the same time, the username and password are propagated to JBoss server via the ClientLoginModule.
When user attempts to access EJB for the first time, the username and password from above should be used to authenticate/authorize user to server (via your LDAP login module.) After that, any calls to the server should not have to touch the LDAP server (i.e. JAAS login does not need to occur) again. This is due to the authentication cache. If you are seeing different behavior, please post more detail.