Re: [foaf-protocols] HTTP request header field for acceptable authentication methods

From: Henry Story <henry.story@bblfish.net> · Date: Sun, 30 Oct 2011 23:11:41 +0100

Bergi this is a very good idea!

I just found the need for something like this while building a test suite for the read-write web project. It discovered that Java require one
to set ssl client authentication to NEED - which is problematic because it means that if the client does not have a certificate, and we ask
him for one the session is going to be broken in an ugly manner. So we don't want that set for the better built browsers that allow 
ssl renegotiation on WANT.  In the code below in line 182 I check if the header contains "Java" before asking for client cert renegotiation.
For sure it would be helpful if I knew that the client had a certificate, because then NEED would not be such a problem.

So +1 for this. We should decide on how to do it and document it - perhaps even in the spec.

   173     r.underlying.context.getPipeline.get(classOf[SslHandler]) match {
   174       case sslh: SslHandler => try {
   175         //return the client certificate in the existing session if one exists
   176         Some(sslh.getEngine.getSession.getPeerCertificates)
   177       } catch {
   178         case e => {
   179           // request a certificate from the user
   180           sslh.setEnableRenegotiation(true)
   181           r match {
   182             case UserAgent(agent) if needAuth(agent) => sslh.getEngine.setNeedClientAuth(true)
   183             case _ => sslh.getEngine.setWantClientAuth(true)  
   184           }
   185           
   186           val future = sslh.handshake()
   187           future.await(30000) //that's certainly way too long.
   188           if (future.isDone) {
   189             if (future.isSuccess) try {
   190               Some(sslh.getEngine.getSession.getPeerCertificates)
   191             } catch {
   192               case e => None
   193             } else {
   194               None
   195             }
   196           } else {
   197             None
   198           }
   199         }
   200       }
   201       case _ => None
   202     }
   203 
   204   }
   205 
   206  /**
   207   *  Some agents do not send client certificates unless required. This is a problem for them, as it ends up breaking the
   208   *  connection for those agents if the client does not have a certificate...
   209   *
   210   *  It would be useful if this could be updated by server from time to  time from a file on the internet,
   211   *  so that changes to browsers could update server behavior
   212   *
   213   */
   214   def needAuth(agent: String): Boolean = {
   215     agent.contains("Java")
   216   }

https://dvcs.w3.org/hg/read-write-web/file/3bb89aaaab51/src/main/scala/auth/X509Cert.scala

On 30 Oct 2011, at 22:59, mike amundsen wrote:

> The idea of advertising support for one or more auth schemes is much
> needed and, IMO, under-utilized right now. HTTP already has a
> mechanism in place for supporting new authentication schemes and for
> indicating preferences.
> 
> Check out the WWW-Authenticate header[1] for details on how servers
> can list various supported schemes and how clients can id and select
> them.
> 
> There is also an I-D[2] underway to create a public registry for new
> HTTP auth schemes.
> 
> Finally, you might be interested in a recent I-D[3] that is trying to
> make it easy for clients and servers to support new auth schemes.
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47
> [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02
> [3] http://tools.ietf.org/html/draft-oiwa-http-auth-extension-00
> 
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
> 
> 
> 
> 
> 
> On Sun, Oct 30, 2011 at 17:38, bergi <bergi@axolotlfarm.org> wrote:
>> Currently my and maybe most other web applications with WebID support
>> have the following flow for user authentication:
>> 
>> - The user sees your web page with reduced content
>> - The user follows the login link
>> - The login resource asks for a client certificate
>> - The WebID gets bound to the session cookie
>> - The server sends a redirect to the original page
>> - Finally the user sees page with the content for that WebID
>> 
>> For example the Java address book application or most robots want to
>> access the resource in a RESTful way and will not use the described
>> flow. I haven't found a way to force the use of a client certificate if
>> the server doesn't ask for one. I propose to use a HTTP header field to
>> tell the server that the client is able to authenticate with a WebID. As
>> such a field could be also useful for other authentication methods I
>> would chose a generic name. There are already some Accept-* fields I
>> would follow that pattern. As it's currently not a standard field I
>> would prefix that field with X-. Multiple values must have the same
>> format as defined for the Accept field. Also the quality parameter must
>> be handled by the server.
>> 
>> Example only with WebID authentication:
>> X-Accept-Authentication: WebID
>> 
>> Example with WebID and Basic authentication:
>> X-Accept-Authentication: WebID, Basic;q=0.9
>> 
>> What do you think about my proposal?
>> 
>> 
>> the bergi
>> 
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
http://bblfish.net/