Interface Channel.Interface.SASLAuthentication.DRAFT2

Interface Index (Compact) | Summary | Description | Methods | Signals | Properties | Types

Methods

StartMechanism (s: Mechanism) nothing
StartMechanismWithData (s: Mechanism, ay: Initial_Data) nothing
Respond (ay: Response_Data) nothing
AcceptSASL () nothing
AbortSASL (u: Reason, s: Debug_Message) nothing

Signals

SASLStatusChanged (u: Status, s: Reason, a{sv}: Details)
NewChallenge (ay: Challenge_Data)

Properties

AvailableMechanisms as (SASL_Mechanism_List) Read only Immutable
HasInitialData b Read only Immutable
CanTryAgain b Read only Immutable
Encrypted b Read only Immutable
Verified b Read only Immutable
SASLStatus u (SASL_Status) Read only
SASLError s (DBus_Error_Name) Read only
SASLErrorDetails a{sv} (String_Variant_Map) Read only
AuthorizationIdentity s Read only Immutable
DefaultRealm s Read only Immutable
SASLContext a{sv} (String_Variant_Map) Read only Immutable

Types

SASL_Mechanism Simple Type s
SASL_Abort_Reason Enum u
SASL_Status Enum u
WARNING: This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Do not include this interface in libraries that care about compatibility.
Added in 0.21.UNRELEASED. (draft 2)
Objects implementing this interface must also implement:

Description

A channel interface for SASL authentication, as defined by RFC 4422. When this interface appears on a ServerAuthentication.DRAFT2 channel, it represents authentication with the server. In future, it could also be used to authenticate with secondary services, or even to authenticate end-to-end connections with contacts.

In any protocol that requires a password, the connection manager can use this channel to let a user interface carry out a simple SASL-like handshake with it, as a way to get the user's credentials interactively. This can be used to connect to protocols that may require a password, without requiring that the password is saved in the Account.Parameters.

In some protocols, such as XMPP, authentication with the server is also carried out using SASL. In these protocols, a channel with this interface can provide a simple 1:1 mapping of the SASL negotiations taking place in the protocol, allowing more advanced clients to perform authentication via SASL mechanisms not known to the connection manager.

Rationale:

By providing SASL directly when the protocol supports it, we can use mechanisms like Kerberos or Google's X-GOOGLE-TOKEN without specific support in the connection manager.

For channels managed by a ChannelDispatcher, only the channel's Handler may call the methods on this interface. Other clients MAY observe the authentication process by watching its signals and properties.

Rationale:

There can only be one Handler, which is a good fit for SASL's 1-1 conversation between a client and a server.

Methods

(Permalink)

StartMechanism (s: Mechanism) → nothing

Parameters

Start an authentication try using Mechanism, without sending initial data (an "initial response" as defined in RFC 4422).

Rationale:

This method is appropriate for mechanisms where the client cannot send anything until it receives a challenge from the server, such as DIGEST-MD5.


Possible Errors

  • Not Available
  • The channel is not in a state where starting authentication makes sense (i.e. SASL_Status_Not_Started, or (if CanTryAgain is true) SASL_Status_Server_Failed or SASL_Status_Client_Failed). You should call AbortSASL and wait for SASL_Status_Client_Failed before starting another attempt.
  • Network Error
  • Raised when there is an error reading from or writing to the network.
  • Not Implemented
  • The server or connection manager doesn't implement the given SASL mechanism. Choose a SASL mechanism from AvailableMechanisms, or abort authentication if none of them are suitable.
(Permalink)

StartMechanismWithData (s: Mechanism, ay: Initial_Data) → nothing

Parameters

  • Mechanism — s (SASL_Mechanism)
  • The chosen mechanism.
  • Initial_Data — ay
  • Initial data (an "initial response" in RFC 4422's terminology) to send with the mechanism.

Start an authentication try using Mechanism, and send Initial_Data as the "initial response" defined in RFC 4422 §3.3.

If the underlying protocol does not make it possible to send initial data, this method will fail.

Rationale:

This method is appropriate for mechanisms where the client may send data first, such as PLAIN.

Having two methods allows any mechanism where it makes a difference to distinguish between the absence of an initial response (StartMechanism) and a zero-byte initial response (StartMechanismWithData, with Initial_Data empty).


Possible Errors

  • Not Available
  • The channel is not in a state where starting authentication makes sense (i.e. SASL_Status_Not_Started, or (if CanTryAgain is true) SASL_Status_Server_Failed or SASL_Status_Client_Failed). You should call AbortSASL and wait for SASL_Status_Client_Failed before starting another attempt.
  • Network Error
  • Raised when there is an error reading from or writing to the network.
  • Not Implemented
  • The server or connection manager doesn't implement the given SASL mechanism (choose one from AvailableMechanisms, or abort authentication if none of them are suitable), or doesn't allow initial data to be sent (as indicated by HasInitialData; call StartMechanism instead).
(Permalink)

Respond (ay: Response_Data) → nothing

Parameters

  • Response_Data — ay
  • The response data.

Send a response to the the last challenge received via NewChallenge.


Possible Errors

  • Not Available
  • Either the state is not In_Progress, or no challenge has been received yet, or you have already responded to the last challenge.
  • Network Error
  • Raised when there is an error reading from or writing to the network.
(Permalink)

AcceptSASL () → nothing

If the channel's status is SASL_Status_Server_Succeeded, this method confirms successful authentication and advances the status of the channel to SASL_Status_Succeeded.

If the channel's status is SASL_Status_In_Progress, calling this method indicates that the last NewChallenge signal was in fact additional data sent after a successful SASL negotiation, and declares that from the client's point of view, authentication was successful. This advances the state of the channel to SASL_Status_Client_Accepted.

In mechanisms where the server authenticates itself to the client, calling this method indicates that the client considers this to have been successful. In the case of ServerAuthentication.DRAFT2 channels, this means that the connection manager MAY continue to connect, and MAY advance the Connection.Status to Connected.


Possible Errors

  • Not Available
  • Either the state is neither In_Progress nor Server_Succeeded, or no challenge has been received yet, or you have already responded to the last challenge.
  • Network Error
  • Raised when there is an error reading from or writing to the network.
(Permalink)

AbortSASL (u: Reason, s: Debug_Message) → nothing

Parameters

  • Reason — u (SASL_Abort_Reason)
  • Reason for abort.
  • Debug_Message — s
  • Debug message for abort.

Abort the current authentication try.

If the current status is SASL_Status_Server_Failed or SASL_Status_Client_Failed, this method returns successfully, but has no further effect. Otherwise, it changes the channel's state to SASL_Status_Client_Failed, with an appropriate error name and reason code.

Signals

(Permalink)

SASLStatusChanged (u: Status, s: Reason, a{sv}: Details)

Parameters

Emitted when the status of the channel changes.
(Permalink)

NewChallenge (ay: Challenge_Data)

Parameters

  • Challenge_Data — ay
  • The challenge data or additional data from the server.

Emitted when a new challenge is received from the server, or when a message indicating successful authentication and containing additional data is received from the server.

When the channel's handler is ready to proceed, it should respond to the challenge by calling Respond, or respond to the additional data by calling AcceptSASL. Alternatively, it may call AbortSASL to abort authentication.

Properties

Accessed using the org.freedesktop.DBus.Properties interface.
(Permalink)

AvailableMechanisms — as (SASL_Mechanism_List)

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

The SASL mechanisms as offered by the server, plus any pseudo-SASL mechanisms supported by the connection manager for credentials transfer. For instance, in a protocol that natively uses SASL (like XMPP), this might be [ "X-TELEPATHY-PASSWORD", "PLAIN", "DIGEST-MD5", "SCRAM-SHA-1" ].

To make it possible to implement a very simple password-querying user interface without knowledge of any particular SASL mechanism, implementations of this interface MUST implement the pseudo-mechanism X-TELEPATHY-PASSWORD.

(Permalink)

HasInitialData — b

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals
If true, StartMechanismWithData can be expected to work (this is the case in most, but not all, protocols). If false, StartMechanism must be used instead.
(Permalink)

CanTryAgain — b

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

If true, StartMechanism and (if supported) StartMechanismWithData can be expected to work when in one of the Failed states. If false, the only thing you can do after failure is to close the channel.

Rationale:

Retrying isn't required to work, although some protocols and implementations allow it.

(Permalink)

Encrypted — b

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

True if this authentication process occurs over an encrypted connection. This does not imply that steps have been taken to avoid man-in-the-middle attacks.

Rationale:

For future support for RFC 5056 Channel Binding it is desirable to be able to use some SASL mechanisms over an encrypted connection to an unverified peer, which can prove that it is the desired destination during the SASL negotiation.

Clients MAY use the combination of this property and Verified to decide whether the PLAIN mechanism is acceptable, for instance.

(Permalink)

Verified — b

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

True if this authentication process occurs over a connection that is protected against tampering, and has been verified to be with the desired destination: for instance, one where TLS was previously negotiated, and the TLS certificate has been verified against a configured certificate authority or accepted by the user.

Clients MAY use the combination of this property and Encrypted to decide whether the PLAIN mechanism is acceptable, for instance.

(Permalink)

SASLStatus — u (SASL_Status)

Read only
The current status of this channel. Change notification is via the SASLStatusChanged signal.
(Permalink)

SASLError — s (DBus_Error_Name)

Read only

The reason for the SASLStatus, or an empty string if the state is neither Server_Failed nor Client_Failed.

In particular, an ordinary authentication failure (as would be produced for an incorrect password) SHOULD be represented by AuthenticationFailed, cancellation by the user's request SHOULD be represented by Cancelled, and cancellation by a local process due to inconsistent or invalid challenges from the server SHOULD be represented by ServiceConfused.

If this interface appears on a ServerAuthentication.DRAFT2 channel, and connection to the server fails with an authentication failure, this error code SHOULD be copied into the Connection.ConnectionError signal.

(Permalink)

SASLErrorDetails — a{sv} (String_Variant_Map)

Read only

If SASLError is non-empty, any additional information about the last disconnection; otherwise, the empty map. The keys and values are the same as for the second argument of Connection.ConnectionError.

If this interface appears on a ServerAuthentication.DRAFT2 channel, and connection to the server fails with an authentication failure, these details SHOULD be copied into the Connection.ConnectionError signal.

(Permalink)

AuthorizationIdentity — s

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

The identity for which authorization is being attempted, typically the 'account' from the RequestConnection parameters, normalized and formatted according to the conventions used for SASL in this protocol.

Rationale:

The normalization used for SASL might not be the same normalization used elsewhere: for instance, in a protocol with email-like identifiers such as XMPP or SIP, the user "juliet@example.com" might have to authenticate to the example.com server via SASL PLAIN as "juliet".

This is usually achieved by using the authorization identity for authentication, but an advanced Handler could offer the option to authenticate under a different identity.

The terminology used here is that the authorization identity is who you want to act as, and the authentication identity is used to prove that you may do so. For instance, if Juliet is authorized to access a role account, "sysadmin@example.com", and act on its behalf, it might be possible to authenticate as "juliet@example.com" with her own password, but request to be authorized as "sysadmin@example.com" instead of her own account. See RFC 4422 §3.4.1 for more details.

Rationale:

In SASL the authorization identity is normally guessed from the authentication identity, but the information available to the connection manager is the identity for which authorization is required, such as the desired JID in XMPP, so that's what we signal to UIs; it's up to the UI to choose whether to authenticate as the authorization identity or some other identity.

As a concrete example, the "sysadmin" XMPP account mentioned above would have { 'account': 'sysadmin@example.com' } in its Parameters, and this property would also be 'sysadmin@example.com'. A simple Handler would merely prompt for sysadmin@example.com's password, and use that JID as both the authorization and authentication identity, which might result in SASL PLAIN authentication with the initial response '\000sysadmin@example.com\000root'.

A more advanced Handler might also ask for an authentication identity, defaulting to 'sysadmin@example.com'; if Juliet provided authentication identity 'juliet@example.com' and password 'romeo', the Handler might perform SASL PLAIN authentication using the initial response 'sysadmin@example.com\000juliet@example.com\000romeo'.

(Permalink)

DefaultRealm — s

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

The default realm (as defined in RFC 2831) to use for authentication, if the server does not supply one.

Rationale:

The server is not required to provide a realm; if it doesn't, the client is expected to ask the user or provide a sensible default, typically the requested DNS name of the server. In some implementations of DIGEST-MD5, the server does not specify a realm, but expects that the client will choose a particular default, and authentication will fail if the client's default is different. Connection managers for protocols where this occurs are more easily able to work around these implementations than a generic client would be.

(Permalink)

SASLContext — a{sv} (String_Variant_Map)

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals

Additional protocol- or mechanism-specific context for the authentication. Only one well-known key is currently defined:

jabber-stream-id (string)
The id attribute of the XMPP stream element, as used in the digest mechanism historically used in Jabber.

Types

Simple Type (Permalink)

SASL_Mechanism — s

A SASL mechanism, as defined by RFC 4422 and registered in the IANA registry of SASL mechanisms, or an unregistered SASL mechanism such as X-GOOGLE-TOKEN used in the same contexts.

As a special case, pseudo-mechanisms starting with X-TELEPATHY- are defined by this specification. Use of these pseudo-mechanisms indicates that the user's credentials are to be passed to the connection manager, which will then use them for authentication with the service, either by implementing the client side of some SASL mechanisms itself or by using a non-SASL protocol. The only such pseudo-mechanism currently defined is X-TELEPATHY-PASSWORD.

The X-TELEPATHY-PASSWORD mechanism is extremely simple:

  • The client MUST call StartMechanismWithData, with Initial_Data set to the password encoded in UTF-8. For simplicity, calling StartMechanism followed by calling Respond is not allowed in this mechanism.
  • The connection manager uses the password, together with authentication details from the Connection parameters, to authenticate itself to the server.
  • When the connection manager finishes its attempt to authenticate to the server, the channel's state changes to either SASL_Status_Server_Succeeded or SASL_Status_Server_Failed as appropriate.
Enum (Permalink)

SASL_Abort_Reason — u

A reason why SASL authentication was aborted by the client.

  • Invalid_Challenge (0)
  • The server sent an invalid challenge or data.
  • User_Abort (1)
  • The user aborted the authentication.
Enum (Permalink)

SASL_Status — u

  • Not_Started (0)
  • The initial state. The Handler SHOULD either call AbortSASL, or connect to the NewChallenge signal then call StartMechanism or StartMechanismWithData.
  • In_Progress (1)
  • The challenge/response exchange is in progress. The Handler SHOULD call either Respond or AcceptSASL exactly once per emission of NewChallenge, or call AbortSASL at any time.
  • Server_Succeeded (2)
  • The server has indicated successful authentication, and the connection manager is waiting for confirmation from the Handler. The Handler must call either AcceptSASL or AbortSASL to indicate whether it considers authentication to have been successful.
  • Client_Accepted (3)
  • The Handler has indicated successful authentication, and the connection manager is waiting for confirmation from the server. The state will progress to either Succeeded or Server_Failed when confirmation is received.
  • Succeeded (4)
  • Everyone is happy (the server sent success, and the client has called AcceptSASL). Connection to the server will proceed as soon as this state is reached. The Handler SHOULD call Close to close the channel.
  • Server_Failed (5)
  • The server has indicated an authentication failure. If CanTryAgain is true, the client may try to authenticate again, by calling StartMechanism or StartMechanismWithData again. Otherwise, it should give up completely, by calling Close on the channel.
  • Client_Failed (6)
  • The client has indicated an authentication failure. The possible actions are the same as for Server_Failed.