[pubcookie-dev] reauth bug

[Russell Tokuyama]

All,

I agree that "reauthenticate" means same username but have the
user supply their credentials again.  In other words, reconfirm
your identity again.  On the other hand, "switch user" should be
another option for Web apps to specify as appropriate and/or
as needed.

Of course, the obstacle is how does the app site communicate
its desire to have the user reauthenticate or switch user to
the Login server?

As far as the authN backend, it should double-check that the
user is doing one or the other given some way to tell which
one is permissible for the app site.

Russ


On Thu, 8 May 2003, RL 'Bob' Morgan wrote:

>
> On Thu, 8 May 2003, Nathan Dors wrote:
>
> > flavor_basic.c has a bug whereby it allows a user to enter a new id and
> > password on a reauthentication request and then sends the original id in
> > the granting cookie. This is a nasty switcheroo. Reauthentication is
> > supposed to reconfirm the identity of the current browser user, so this
> > needs to be fixed.
>
> Since Larry asks, let me discuss the policy issue here.  The scenario is:
> user goes to site A, is sent to weblogin, logs in as bob, is sent back to
> site A where session is established as bob.  User goes to sites B and C
> and via SSO establishes session as bob.  User goes to site D which has
> PubcookieSessionCauseReAuth set, arrives at weblogin, and, the way
> pubcookie 3.0.0-rc1 works, is greeted with regular username/password
> dialog.  User logs in as bob2, is sent back to site D and starts session
> as bob2, and now has some open sessions as bob and some as bob2.  You
> might say:  that's OK, if they have 2 IDs they must know what they're
> doing, no problem.  We say:  this is a gun aimed at the user's foot, we
> want to promote a weblogin-mediated session concept here, meaning that the
> user has to logout first before logging in as another ID.  By setting this
> directive, site D doesn't mean "permit user to log in as someone new",
> they really just mean "make user enter their password now".  We think
> preserving the sensibility of the session concept is more important than
> supporting those few users that might get benefit from logging in as a
> second ID.
>
> If folks felt strongly that this is a site option rather than an obvious
> choice for pubcookie to make, I spose it could be made configurable.  I
> can tell you that at our site we'll want it set so the user can only
> confirm the password on their existing login ID, not login as a new ID.
>
> Yes?
>
>  - RL "Bob"
>
>
> _______________________________________________
> pubcookie-dev mailing list
> pubcookie-dev at u.washington.edu
> http://mailman.u.washington.edu/mailman/listinfo/pubcookie-dev
>