Jun 25th, 2009, 01:36 PM
How to keep a session?
I have deployed some service methods on my tomcat web server using the HttpInvokerServiceExporter remoting configuration and have set up a java swing remote client that accesses my services using the HttpInvokerProxyFactoryBean. Authentication works fine on any web application browser accessed interfaces and I assume the correct way to do authentication on my remote client is with the RemoteAuthenticationManager. This only returns a list of GrantedAuthorities and not the actual Authentication object or Principal object giving me a limited amount of information to work with. Such as not knowing if an account is locked, or expired, credentials expired, session id, etc. After authentication I am using BASIC authentication with my HTTP requests to my services in order to do authorization and re-authentication if needed using an implementation of the CommonsHttpInvokerRequestExecutor that puts the username/password in the HTTP header.
Using this implementation I have no control over sessions from my client, and I can't use concurrent-session-control. It seems as if new sessions are created often and in order to attempt to reduce the number of times authentication hits my LDAP server I have set create-session to always as this seemed to help.
I was hoping for a configuration that allows my remote client to log a user in and to use a session until the session times out, at which time a new session would be created on the next server hit, or until the user logs out. I have read on the forums about some people passing around a ;JSESSIONID in order to gain some control over session handling. But I have also read that ;JSESSIONID's can be reused by the server in some circumstances, which would be bad. Using the ;JSESSIONID also doesn't SEEM like the right way to handle this problem.
So now I'm stuck not knowing how to proceed or if what I have is ok, or as good as I can get out of spring. Any help or guidance, or hints on where to look would be GREATLY appreciated. I have been reading everything I can find and trying to get this worked out now for like 6 months. Starting to feel like a dummy.
Jun 25th, 2009, 02:53 PM
In many situations clients don't need to know if the account is locked, and it could be considered a security compromise to tell the client that. The most "agreed on" contract is "if you authenticated successfully" then "you are entitled to know which operations you can perform (within the context defined by how you authenticated)". That is exactly what the RemoteAuthenticationManager interface says.
You can add extra methods to your service interface that give you other properties of the principal, once your client has successfully authenticated but that is really up to you.
Using JSESSION seems like the way to achive what you want. It is exactly what the web-browser does; if you are using httpclient, it has some support for cookies so you can send the session ID with the requests. I'm not sure how spring implements session timeouts, however; I have to look into that myself; probably a filter you add.
Jun 25th, 2009, 04:26 PM
Well, at least I am using the RemoteAuthenticationManager correctly even if I do find it limiting for my users to not know that their password expired and needs changed, or if there account was locked out due to say too many incorrect login attempts. How else would one let the user know their password expired and needs changed? Or, did I not notice and that results in a successful authentication from which I could then request the details?
So, is the proper method to do this to put the current JSESSION in a cookie for every http response header on the server and then cache this on the client and put it into a cookie in my http
requests header on the client side when I call my service methods?
Last edited by adamarmistead; Jun 25th, 2009 at 04:41 PM.
Jun 25th, 2009, 06:58 PM
You could look at the source for the server end to the interface (RemoteAuthenticationManagerImpl.java) and subclass it to override attemptAuthentication(). Just encode the special cases you are interested in as RemoteAuthenticationException (s) so you can inform your user. It already does translate the exception message so you might be able to parse that on your client without modification, or you could arrange your server class to include some message formats that your client expects.
Originally Posted by adamarmistead
Tags for this Thread