Stateless session handling?

[Tamas Hegedus]

I have been trying to set up a Google OpenID Client login to my webapp with pac4j-dropwizard, but we are running multiple instances of the same application so the cookie is only working 50% of the time.

Are there any suggestions how am I supposed to do session handling in this case? I was thinking about storing the whole session in a cookie, so nothing is stored on server side, but I don't know how should I approach this.

Have anyone had some experiences similar to this?

[victo...@gmail.com]

I don't understand what you mean by "we are running multiple instances of the same application so the cookie is only working 50% of the time".

Do you mean that when a user is connected to the application (with an http session setup at the beginning), it can connect to one or the other of the instance of the application so in practice, if its session is setup on instance 1, and then continue on instance 2, then instance 2 does not recognize it?

If it is the case, this has nothing to do with pac4j and is purely a problem of distribution, you have two solutions I think (I'm not expert on the question :):
 - use a distributed session manager in Jetty (the container used by dropwizard) so that all the instances session manager are backed up by the same data (and continue using the same solution as before with pac4j which will use the session store provided by Jetty). For example use something like https://github.com/martindow/dropwizard-hazelcast-session (I'm pretty sure there are other integrations, or look for Jetty based solution, since a dropwizard bundle simply wraps this kind of thing in a nice class).
 - as you say, change the architecture so that sessions are handled by users and passed with every request. For this, you need to use something like JWT or your own way of storing the session data (the oid token? I don' know openid well :). I think it would be cleaner to solve the problem like this (because you don't need some global session store that will be a SPOF for your system and it will be easier to scale in the future by adding more instances, maybe geographically distributed so that using a shared session store is a problem...) but on the other hand, it is more complex to setup. I think there is ways to do it with pac4j (using direct clients which are session-less) but I don't know how unfortunately, Jérôme would know I suppose. I see there is a DirectCasClient that does this kind of thing for CAS, so maybe you need to develop a similar solution. Sorry for not being so helpful :)

[Tamas Hegedus]

Yes, that's exactly the problem. I prefer the second solution too, and I thought there would be a solution with pac4j for this, I think most applications run more than one instance. I will take a look at the DirectCasClient, but I am really surprised that there isn't a clean solution for this problem.

Thanks for your comment!

[jez prime]

Given that sessions are about far more than just authentication, session management should primarily be the responsibility of the web framework/app server, not the security framework which should just be able to hook into what the hosting framework provides. Put another way, I don't think it would be wise for pac4j to provide a solution which potentially conflicts with one a web framework provides, although it would be possible (Play for example used to write all session state to a cookie by default, pac4j could do similar with its auth session, but that would require signing and, I would argue, encryption.

It wouldn't be hard for you to write a cookie-based SessionStore implementation and submit it as a PR though.

[victo...@gmail.com]

I agree with you Jez, as long as you consider traditional web architectures.

But nowadays, there is more and more people working with micro-service like architecture where the client is responsible of giving a token to each services to identify itself.
The token is retrieved in the beginning and contains all the needed information of the session, usually in an encrypted way (e.g. JWT), so that the various services (here the same application duplicated) can look it up directly from the data given by the client, usually using a private key only known to the services (again, that's how JWT is meant to work).

It is actually the same discussion as https://groups.google.com/d/topic/pac4j-users/qjorvxOmSrk/discussion in a way, you should also take a look at it Tamas.

The main difference is that Tamas wants to use the infrastructure provided by pac4j to do the google openid authentication, and it's not as easy as checking credentials in a db as with the other discussion.

Hence the potential need for something from pac4j to use existing authenticators/clients but without enforcing the workflow of indirect clients (so yes, I was wrong, Tamas, you are right to expect pac4j to have an answer to this question, but you are ahead of your time, so it's not yet solved :P).

Maybe another solution would be to use the indirect google openid client to do the authentication but return a JWT token from the callback endpoint so that later on, you can use it to authenticate the user… but I feel there is going to be a lot of hacking to make it work…

Notice that if you expect to only have a few instances of the application on the same network, it would maybe be much easier to use a distributed session store for now and maybe help us on the side to better think about a clean solution with pac4j to the stateless session handling :)

[victo...@gmail.com]

Tamas, you can also follow the discussion on this issue: https://github.com/pac4j/jax-rs-pac4j/issues/24 on this matter.

Maybe through the use of an alternate SessionStore it could be possible to make your use case to work. If you investigate it, I would really interested in your findings!

[Tamas Hegedus]

Unfortunately I had to move on to a different solution because I have to keep a deadline, but I'll keep following the linked issues and try to share my thoughts if I have any.

Thanks for all the answers!

[Anton Piatek]

Did you consider configuring your load balancer/reverse proxy to pin sessions to the same server?