- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Tue, 20 Jan 2009 00:02:43 +0100
- To: ietf-http-wg@w3.org
Hi all, For the purpose of my http-cookie-auth I-D [1], I'm currently doing a survey of the current authentication mechanisms (other than RFC 2617) used "on the wild." Most Single Sign-On systems involve a redirection from the Service Provider (a.k.a Consumer) to the Identity Provider (which redirects back to the SP with some token or "assertion", but that's not the concern here). In some cases, the SP and IdP share the same "root domain" (e.g. docs.google.com, mail.google.com, www.google.com/reader, www.google.com/accounts; http://fr-fr.facebook.com, https://www.facebook.com) so a 401 (Unauthorized) could be used (see example 2 in draft-broyer-http-cookie-auth [1]), and access granted through a cookie with the appropriate Domain attribute value (in Google's case, Domain=.google.com), even though using distinct cookies might be a better choice for security. In other cases though, it is not possible (the SP and IdP do not share a common "root domain", as is the case for e.g. www.flickr.com and login.yahoo.com). There are possible workarounds using a meta refresh and/or some javascript (see notes about the yet-to-be-written example 3 in draft-broyer-http-cookie-auth [1], a no-code demo can be found at [2], file source avail. at [3]) but that's not ideal. In both cases, for instance, if the SP runs on HTTP and the IdP on HTTPS, if the 401 payload contains an HTML "login form", the user cannot know before hand that the form will be submitted on a secured channel to the IdP (this is a problem with the UA, but IMO not only, as it's also related to CSRF and to phishing). I therefore wonder if a new 3xx status had been proposed before, in order to communicate lack of authorization (same as a 401) but redirecting/deferring to another resource to authenticate the user. If it has not been proposed/discussed before, would HTTPbis be a good place to define it, or should/could I include it in draft-broyer-http-cookie-auth (as cookies are the only non-SSL-client-cert non-RFC2617 "authentication" mechanism that I know of) or some other I-D? If people want some "literature" about such SSO systems, one is spec'd as part of SAML 2.0 [4] in the SSO profile. [1] http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html [2] http://ltgt.net/tests/http-cookie-auth/test01/ [3] http://hg.ltgt.net/http-cookie-auth/file/tip/tests/test01 [4] http://saml.xml.org -- Thomas Broyer
Received on Monday, 19 January 2009 23:03:28 UTC