Re: Past Proposals for HTTP Auth Logout

> I'd argue that the federated case, or even the problem of invalidating
> application sessions in a load-balanced web application makes
> it a total-system problem.

There is a big picture to look at, certainly, but one can't lose sight
of what's actually going on in application development today.  I do
application penetration testing and security code review for a living,
so I look at a lot of applications.  The vast majority simply use
cookie-based frameworks and any advanced authentication/authorization
frameworks (if used at all) are not exposed to clients at all.

> There does seem to be a user-interface and management issue 
> with providing a unified interface to all the possible sorts of login 
> credentials, that gives their scope and human meaning.

I'm merely trying to make existing standards usable in practice.  The
key to this is allowing application developers to control the user
experience for login and logout.

> Off-hand, we've got Basic and Digest Auth passwords, kerberos
> tickets in several forms, encrypted cookies, SAML assertions,
> and probably stuff tied to session keys in the HTML or URLs.

I'm not concerned about browser cookies.  They're a de facto standard
and, likely because of this, are riddled with security problems.

I'd like to remove the barriers to entry for Basic and Digest
authentication, and hopefully, any additional HTTP authentication
schemes. If Basic and Digest were widely usable, I believe future ones
would be easier to transition to.  

> There are too many messy issues in the big picture...

Can you name more, besides the two below?


> If I use a magic new feature to "log out" of an intranet site 
> autheticated with MSIE, have I just dumped the kerberos tickets 
> for our AD domain?

That could be kerberos-specific behavior.  As I proposed in an earlier
email, a response header could define the auth scheme, realm, and any
additional scheme-specific information.  I suppose an auth scheme
could decide not to implement such a feature.


> Can you provide a human-readable, non-spoofable way to label
> the credentials?
> 
> Can the protocol be spoofed 

Optional scheme-specific information could easily provide a signature
or other integrity protection for the logout response itself,
autheticating it.  That one, at least, I thought of.

Any general authentication control header shouldn't cause problems for
existing auth schemes, but if it's up to the scheme to define that,
then that shouldn't be an issue.

thanks,
tim

Received on Saturday, 9 January 2010 23:33:28 UTC