CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cosign Loop Breaking

What Mark says strikes a chord with me. In particular, my first reaction was that it's "not your problem", and similar to what Mark said, a somewhat disturbing notion: specific code in COSIGN to deal with somebody's weirdo application. 8)

But maybe I've just offended the person with the weirdo application 8), and maybe the rationale for having protection from this in COSIGN is clearer if we know the types of misconfigurations where this can happen. Could you share more details?

It may be worth noting that in either case the user is not particularly well served; although having this feature in COSIGN provides for an elegant exit, the user is likely still just as stranded. My point here is it's tough to justify based on the user experience.

Mark Montague wrote:
On Thu, 3 Jun 2004, johanna bromberg craig wrote:

There are a few misconfigurations that can cause a loop where a service
will set a cookie, redirect back to the central cosign server, which
will try and register the cookie, succeed, redirect back, where the
"check" will fail, set a new cookie, redirect, re-register, etc. This
will go on until the browser detects "too many redirects" ( this
threshold varies by browser ) at which point a very unhelpful message
will be thrown by the browser and the user is "stranded."

I propose that we add some code to the cgi that keeps track of the
number of REGISTERs in a given time period.  Our current idea is to
tack on a time stamp and a count to the end of the login (cosign=)
cookie, so we'd have:

cosign=[random_bits_here]/[time in seconds]/[number of registers since
that time]

If a give login cookie exceeds X registers in N seconds, the cgi can
throw a proper error screen giving the user some *actual* information.
:) The current defaults I'm thinking of are 10 registers in 30 seconds.
This is fairly arbitrary, and just where I'm starting?

I've thought about this for a while.  The solution seems like it
will work, and I can't think of problems that it would cause.  I
can't think of any advantage that a person could obtain by
deliberately falsifying the time or number of registers in their
cookie that they couldn't obtain currently simply by making up
their own cookies themselves from scratch.

I'm less than 100% comfortable with this solution, though, because
I don't know that it's the best solution to the problem; you just
say "there are a few misconfigurations that can cause a loop".
What are these misconfigurations?  I'd like the chance to explore
them and see if someone on the mailing list can come up with a way
to ensure that the misconfigurations never occur as a preferable
option to making the cookie more complicated and adding extra
functionality and special-case logic to the "core" part of the
cosignd code.  It may be that the solution proposed is the best
one; my point though is I don't know that because it's not clear
to me what sorts of misconfigurations are causing the problem.

I'm not saying "don't implement the proposed solution", I'm just
sharing my thoughts in general.

                Mark Montague
                LS&A Information Technology

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010