[Bug 14003] Connection: interface to ask for credentials (SASL auth channels)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=14003

--- Comment #20 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-18 11:00:54 PDT ---
ServerAuthentication
====================

ServerAuthentication could do with a high-level explanation of how it happens:

- When is it dispatched? I infer that it's while the Connection is CONNECTING,
but that should be stated up-front.

- What properties can it be expected to have? Most of the text from
ServerTLSConnection is probably applicable.

- Can you have more than one ServerAuthentication in series? The SASL RFC says
you can't have more than one SASL negotiation, if I'm reading it correctly, but
you could conceivably have a round of SASL followed by a round of captcha, or
vice versa. If you can, would it mean "at least one must succeed" or "all must
succeed"?

- Can you have more than one ServerAuthentication in parallel? If you can,
would it mean "at least one must succeed" or "all must succeed"?

Are the username and realm in Auth_Details the same as SASL RFC 4422's
"authorization identity strings" or are they intended as something to put in
the UI presented to the user or what?

Please note the distinction between authentication and authorization
identities. A non-empty, non-omitted authorization identity means I want to
authenticate with one identity (authentication identity), then act as a
different identity. For instance, that could mean "authenticate as root, using
your root powers to impersonate eeejay without knowing his password", or
conversely, it could mean "the sysadmins can authenticate with their own
identities, and are authorized to impersonate announcements at example.com when
they do so". We don't necessarily need to support that, but we should get the
terminology right so we can support it later if desired.

SASL
====

Abort_Reason is too vague a name - types are a flat namespace. It should be
SASL_Abort_Reason.

StartMechanism can't distinguish between no initial data, and initial data of
zero length. (Not as stupid as it sounds: RFC 4422 §4(3)(a) requires these to
be distinct.)

We don't have a way to emit an 'ay' of additional data with a successful
outcome (i.e. carried on a successful StateChanged), which is a SHOULD in RFC
4422 §4(3)(c). Again, "no additional data" is a value distinct from the
zero-length string.

Is AvailableMechanisms immutable? (My guess: yes.)

Is Secure immutable? (My guess: yes.)

What is CurrentChallenge when there is no current challenge? (This is not as
stupid as it sounds: the empty octet-string is a valid challenge.)

We should document that only the Handler may call StartMechanism.

Do we really need CurrentChallenge at all? Couldn't we just say that the
Handler can't call StartMechanism until it has connected to the NewChallenge
signal, and it makes no sense for anyone else to call that method?

It's not immediately obvious what the state transitions are; I'll try to dig
that out from Gabble.

There are no tp:possible-errors anywhere, which seems like an oversight.

I would assume that:

- Respond() is only valid to be called while In_Progress; similarly,
NewChallenge makes no sense unless In_Progress

- Abort() can be called at any time, except when Server_Failed or Client_Failed
when it would have no effect (or can it be called in Server_Failed to convert
it into Client_Failed? answers on a postcard)

- Close() can be called at any time, and has the same effect as calling Abort()
with errors ignored, and then Close()

Can StartMechanism be called in In_Progress, Server_Succeeded, Client_Accepted
and Succeeded states, to restart authentication gratuitously?

Why does Abort() take an Abort_Reason, but SASL_State has a DBus_Error_Name?
Shouldn't they both have the same (perhaps both)?

We should perhaps write to IANA and register X-GOOGLE-TOKEN as a SASL
mechanism, since Google have failed to do so (if I read the RFC correctly,
there's no particular provision for "X-" SASL mechanisms, but anyone can
register a SASL mechanism, and no particular approval is required).

Do we need a way for the authenticator to get the server's GSSAPI host-based
service name (RFC 4422 §4(1))? I expect that that'd be a constant string + "@"
+ the hostname, for basically every protocol we support.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.