Re: JavaHL: support for authenticating with different credentials for the same realm

On 06.02.2014 15:27, Marc Strapetz wrote:
> For SmartSVN, we are looking for a way to support multiple credentials
> (username and password) for the same realm. When using the command line
> client, --username will do the job, however this option is not well
> suited for a GUI client. Here, a quite flexible as well as intuitive
> approach would be to support the user_at_-specification as part of the URL.

The username part of the URL is stored in the Subversion working copy,
but it's not used for authentication. This is in accordance with RFC 3986:

http://tools.ietf.org/html/rfc3986#section-3.2

note especially this quote: "Many URI schemes include a hierarchical
element for a naming authority so that *governance of the name space
defined by the remainder of the URI* is delegated to that authority ..."

This means that, for example, in an HTTP url

    http://user@example.com/path

the "user" part must not be interpreted as an authentication token;
instead, the whole "user_at_example.com" part define the meaning of "/path".

This is evident in Subversion's default implementation of the svn+ssh://
protocol, where the username in the authority element determines how the
SSH connection is made, but has no bearing on how the client
authenticates to the svnserve process at the other end of the SSH tunnel.

It is also conceivable that an HTTP server would, for example, define
virtual hosts based on the whole authority, not just the host and port
part that Apache HTTPd uses. I don't know of a server that does that,
but I can't find anything in either the URI spec or the HTTP spec that
would forbid this.

> To be able to implement that, I'd suggest to extend JavaHL in either of
> the following ways:

[Just a side note -- there's no meaningful distinction between JavaHL
and Subversion in this case.]

> (A) UserPasswordCallback.prompt(String realm, String username) should
> give the user_at_-user from the requested URL as the default "username", if
> present. Hence, precedence for this default would be:
>
> (a) ISVNClient.username() (--username-option)
> (2) "user@" from URL
> (3) system user (as currently)

Apart from (2), this is already what you get.

> (B) rework UserPasswordCallback to include the accessed URL, like:
>
> UserPasswordCallback.prompt(String realm, String username, String url)
>
> (B) will allow to parse the user@ from the specified URL and has the
> additional advantage that the credentials prompt will also be able to
> display for which URL credentials are required. This can be helpful to
> design a clearer "Login" dialog.

Given the semantics specified by the RFC, I'd say it's invalid for any
client to interpret the authority part of the URL differently than the
current code behaves. I appreciate that the misconception that the user@
part of the authority is an authentication token is quite common, but
it's just that -- a misconception.

> Taken as a whole, I'd appreciate a more general review of
> UserPasswordCallback which is currently hard to implement for a GUI
> client: e.g. to provide better support for SSL, more specific methods
> than askQuestion with a single String-parameter would be needed. I can
> post a proposal, if this will be helpful.

That I can heartily agree with. Having spent the last several months
hacking JavaHL, I have a hard time understanding how anyone could have
ever written a sane authentication UI with that callback. Ironically,
the underlying C API already provides more detailed information (in most
cases; not always).

I have a todo long list of JavaHL-related API enhancements, and a rehaul
of the authentication API -- not just the callback, but the credentials
managment, too -- is on the top.

> Thanks for your consideration.

Any time.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com