[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: zxid and shared/distributed filesystems?
Eric Rybski wrote:
> Hello all,
> I have a few questions about zxid's session management. Currently,
> interested in a redundant SP implementation using an existing
> web server infrastructure. Since zxid is solely filesystem based at this
> time, I'm considering a few options for central session storage:
> 1. Use a single SP server and proxy SSO requests to this server.
Does not give you redundancy.
> 2. Use a NFS mount for /var/zxid/ses (and likely /var/zxid/log/rely).
> 3. Use a virtual filesystem for /var/zxid/ses
> (and likely /var/zxid/log/rely), such as memcachefs or mysqlfs.
Better. For simplicity, I would simply share /var/zxid across the farm.
Please note that if the objective is scaling / load balancing, sharing
across farm is good idea. If objective is fault tolerance, you need
to be very careful and conscious about how you provide the shared
filesystem in a redundant fashion.
> Given how zxid currently manages sessions via pseudorandom numbers, would
> be safe to run concurrently across multiple webservers on a centralized
Current session IDs are quite short, 48bits, see zxidconf.h ZXID_ID_BITS,
for sake of convenience and conciceness.
The standard assumption about "insignificant" probability of collision
in absence of any explicit duplicate check is that 128 bit random
number is sufficient (it is more probable that you will have collision
due to error induced by cosmic ray than on statistical basis).
Thus, I would encourage you to review what your tolerance for collision
is and adjust ZXID_ID_BITS accordingly.
Adjusting for the above consideration, I do not see any problem in running
across a farm of servers that share filesystem.
> It seems most SP/IdP implementations use a single-server
> optional failover-server) concept, but my target environment is generally
> better suited for distributed web services and already has infrastructure
> place for options 2 or 3.
> My priorites are: 1. security; 2. fault tolerance. Thus, if a centralized
> filesystem could compromise user security in any way (e.g. session
> shared due to pseudorandom collisions), a single SP server would likely be
> the better option.
Even single SP code does not make duplicate check. It assumes you
adjusted ZXID_ID_BITS to correspond to your tolerance of collision.
> Note: I see that I can compile ZXID_ID_BITS with a fairly high value (i.e.
> 144), so the chance of a pseudorandom collision should be extremely
> improbable in a real-world context.
Right. 144 is base64 rounded number above 128. This is what I recommend
for high security. However, many "commercial grade" apps may want to
optimize for compactness and convenience while maintaining "reasonable"
security. Hence my default of 48 bits.
Before anyone has knee-jerk reaction about security, please do
provide analysis about the right number of bits. I am not interested