Load balancing simpleSAMLphp with persistence
Stephen Edmonds
Greetings,
We have been looking into using simpleSAMLphp as an Identity Provider
against our existing CAS service. I have been able to get it working, but
am now at the point of working out how it would be configured in
production, in particular in a farmed environment.
On the maintenance and configuration page there is a note that phpsession
"will not work in a load-balanced environement."
What exactly does this mean? All forms of load-balancers, or just certain
configurations?
As far as I understand PHP session, it is only possible to store data for a
particular user. So the data can be stored if the access is from the
browser, but if the SP accesses the IP directly (artifact resolution for
example) how can it access the data?
Our normal load-balanced configuration is with persistence, so a user will
stick to a particular node. As long as that node is up I don't see why
using PHP session wouldn't work as the node has the data.
If that node does go down and the user is bounced to another one, we don't
see that as an issue as they would simply be reauthenticated through CAS.
Does anyone have any advice or recommendations?
Thanks,
Stephen
--
Stephen Edmonds
Senior Portal Developer / Integrator
Flexible Learning and Teaching Program
Information Technology Services, Monash University
Andreas Åkre Solberg
On 9. mars2009, at 05:18, Stephen Edmonds wrote:
> We have been looking into using simpleSAMLphp as an Identity Provider
> against our existing CAS service. I have been able to get it
> working, but
> am now at the point of working out how it would be configured in
> production, in particular in a farmed environment.
>
> On the maintenance and configuration page there is a note that
> phpsession
> "will not work in a load-balanced environement."
>
> What exactly does this mean? All forms of load-balancers, or just
> certain
> configurations?
PHPsession stores sessions in local files. When the user is then sent
to the other instance in your loadbalannced setup, the session is
obviously lost, or not available.
It may be possible that it works if you put the files on a shared file
directory (NFS or similar). I have not tried that.
We reccomends memcache for session storage, when loadbalancing.
As you write below, if you have a true persistent loadbalancer and
does not need failover, it will work with phpsession. True persistence
would require LB to terminate SSL, and be based on cookies.
> As far as I understand PHP session, it is only possible to store
> data for a
> particular user. So the data can be stored if the access is from the
> browser, but if the SP accesses the IP directly (artifact resolution
> for
> example) how can it access the data?
simpleSAMLphp does not use artifacts.
> Our normal load-balanced configuration is with persistence, so a
> user will
> stick to a particular node. As long as that node is up I don't see
> why
> using PHP session wouldn't work as the node has the data.
Sure that will work fine as long as the user is sent to the same
instance. But if you want fail-over functionality, the user will not
have single sign-on.
> If that node does go down and the user is bounced to another one, we
> don't
> see that as an issue as they would simply be reauthenticated through
> CAS.
True. But when the session is lost, the idp does not longer have the
full list of online SPs in the session. That means you will not be
able to perform global logout in this case.
> Does anyone have any advice or recommendations?
We have good experience with memcache. Really easy to setup, and it
'just works'...
--
Andreas Åkre Solberg
=andreas
http://rnd.feide.no
Stephen Edmonds
Thanks for the info.
I do have further questions about the failure modes of phpsession and memcached.
Setup 1: phpsession as data store and LB with persistence. Users will keep accessing the same node, the node that has their data in phpsession
Setup 2: memcached as data store in parallel with Apache on all nodes. Users don't need to access the same front end node, but the memcached node that has their data will remain constant
As far as I understand memcached, it does not support failover. If a memcached node fails, any data that would have been stored on it can no longer be stored. You have to accept this gap in the data set until the node can be restored. Taking the node out of the list of memcached hosts isn't an option as that will invalidate ALL data stored in memcached.
So in setup 1 if a node is lost:
- user data that was on that node is also lost
- users are bounced over to another node which will start storing their data
In setup 2 if a node is lost:
- users who were accessing the node are bounced to other nodes
- user data in that memcached instance is lost
- users on any node who would have their data stored on that memcached instance cannot have their data stored.
To me it is that setup 1 means that some users would have to reauthenticate, while setup 2 means that some users are blocked from reauthenticating
Is all of this correct, or have I severely misunderstood something?
If it is correct then we don't consider memcached an option for data that isn't cache data, we would rely on persistence and phpsession, or add a new data store that used a database.
Thanks,
Stephen
--
Stephen Edmonds
Senior Portal Developer / Integrator
Flexible Learning and Teaching Program
Information Technology Services, Monash University
| From: | Andreas Åkre Solberg <andreas...@uninett.no> |
| To: | simple...@googlegroups.com |
| Date: | 09/03/09 05:57 PM |
| Subject: | Re: Load balancing simpleSAMLphp with persistence |
Andreas Åkre Solberg
On 10. mars2009, at 01:00, Stephen Edmonds wrote:
> I do have further questions about the failure modes of phpsession
> and memcached.
>
> Setup 1: phpsession as data store and LB with persistence. Users
> will keep accessing the same node, the node that has their data in
> phpsession
> Setup 2: memcached as data store in parallel with Apache on all
> nodes. Users don't need to access the same front end node, but the
> memcached node that has their data will remain constant
>
> As far as I understand memcached, it does not support failover. If
> a memcached node fails, any data that would have been stored on it
> can no longer be stored. You have to accept this gap in the data
> set until the node can be restored. Taking the node out of the list
> of memcached hosts isn't an option as that will invalidate ALL data
> stored in memcached.
There is no replication built into standard memcached, but
simpleSAMLphp has a replication layer on top of memcache that will
keep the users session updated on both instances. Consider you have
node A and B as frontend, and they run one memcache each (to make the
use-case simple):
1) User access node A. But session is then replicated on both A and B.
2) Node A goes down
3) User is sent to node B on next request. Session is available on
node B as well
4) Users session is modified and a new version is stored in node B
5) Node A comes back
6) Now the session only exists in node B
7) User access node A again, and failes to find a session. The user
will find the session on node B and replicate that back to node A.
Worth to mention, if node A goes down, and then afterwards B goes
down, and the user has not accessed the system in the mean time, then
the user's session will be lost, and the user would have to re-
authenticate. This only happens if 'goes down' means that the computer
is restarted or by some means the memcache memory is dropped. If a
node just loose availability on the web, sessions are not lost, but
are unavailable for a while.
I can also mention that there exists several alternative
implementations of memcache than memcached. Some of these have built-
in replication, and also when one node wakes again it is automatically
updated from the other node.
> So in setup 1 if a node is lost:
> - user data that was on that node is also lost
> - users are bounced over to another node which will start storing
> their data
Yes.
> In setup 2 if a node is lost:
> - users who were accessing the node are bounced to other nodes
> - user data in that memcached instance is lost
> - users on any node who would have their data stored on that
> memcached instance cannot have their data stored.
No, this is not the case. See my description above.
> To me it is that setup 1 means that some users would have to
> reauthenticate, while setup 2 means that some users are blocked from
> reauthenticating
>
> Is all of this correct, or have I severely misunderstood something?
>
> If it is correct then we don't consider memcached an option for data
> that isn't cache data, we would rely on persistence and phpsession,
> or add a new data store that used a database.
--