Re: Issue on authentication in yesterday's telecon

Hi Rafel,

This is all true, but when using XForms in current browsers, you will
invariably get the normal browser login prompt. I think the suggestion
is that this could be a set of controls defined by the author.

(Also, there are other types of authentication, such as that use by
GData, which I don't believe browsers handle natively.)

One way to do this _now_ is for the form author to know that a certain
resource is protected, and so ask for the user name and password in
advance--i.e., before the actual request. The new XForms 1.1 'header'
feature would then allow a form author to send the correct data and so
avoid the 'challenge' from the server altogether.

Another way would be to have an action handler that processes the
xforms-submit-error event, and makes some controls available to the
user so that they can enter a user-name and password, before
continuing as before, using the headers. New features in XForms 1.1
allow the author to get access to the error information in the event
handler, so this should be possible, although the danger would be that
code would end up being written to cope specifically with HTTP.

So, what I think we are missing is some kind of declarative way to
encapsulate this whole process, and that is something that we need to
be discussing. For example, we might decide to introduce another event
that indicates that a submission requires a login, and use that to
show some controls to the user:

  <xf:submission ...>
    <xf:action ev:event="xforms-submit-authentication-required">
      <xf:toggle ... />
    </xf:action>
  </xf:submission>

This has the advantage of making the whole question non-HTTP--specific.

We might even go to a much 'higher' level and indicate on the
submission itself that some part of the form is to be used if an
authentication is required:

  <xf:submission authentication="auth" ... />
  .
  .
  .
  <xf:group id="auth">
    ...
  </xf:group>

Or we might do something similar, but using instance data.

I think the answer will be more difficult than these simple proposals
indicate, but hopefully it gives a sense of what we _could_ do.

Regards,

Mark

On 19/04/07, Rafael Benito <rbenito@satec.es> wrote:
>
>
>
>
>
>
>
> Hi all,
>
> some comments on yesterday's issue about http authentication.
>
> This authrentication is triggered by the server returning a 401 message  (Unauthorized) to the browser when a server resource is protected and session  credentials are not sent in the request by the browser. The authentication  method in the header (WWW-Authenticate) can be "Basic" or "Digest".
>
> Then, the browser sends user and pasword to the server. In case "digest" is  requested, the password is hashed with MD5. I am not sure whether other hash  functions are allowed. Otherwise, the user  and password are Base-64 encoded.
>
> The server checks the authorization of the user and proceeds normally if  everything is OK or returns a 401  message if it fails.
>
> IMO, this process does not require any additional markup in the XForms spec.  It should be all internally handled by the submission module.
>
> A different issue is whether the spec should state that this authentication  methods have to be supported by the submission module.
>
> The same issue could be extended to authentication with digital certificate  within the SSL protocol. Furthermore, proxy authentication could also be  considered.
>
> Regards,
>
> Rafael Benito Ruíz de Villa
> Director Area  e-business
> Móvil (+34) 617 314 293
> rbenito@satec.es
>
> MADRID
> Avda. Europa, 34 A
> 28023 Aravaca
> Telf.: (+34)  91 708 90 00 / 91 211 03 00
> Fax: (+34) 91 708 90 90 / 91 211 03  90



-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 19 April 2007 11:09:52 UTC