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 | |
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 | |
DefaultUsername | s | Read only | Immutable | |
DefaultRealm | s | Read only | Immutable |
Types
SASL_Mechanism | Simple Type | s | |
SASL_Abort_Reason | Enum | u | |
SASL_Status | Enum | u |
Description
A channel interface for SASL authentication, as defined by RFC 4422. When this interface appears on a ServerAuthentication 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. As a result, this interface does not REQUIRE ServerAuthentication to allow for a potential future Channel.Type.PeerAuthentication interface.
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:
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:
Methods
StartMechanism (s: Mechanism) → nothing
Parameters
- Mechanism — s (SASL_Mechanism)
Start an authentication try using Mechanism, without sending initial data (an "initial response" as defined in RFC 4422).
Rationale:
Possible Errors
- Not Available
- Network Error
- Not Implemented
StartMechanismWithData (s: Mechanism, ay: Initial_Data) → nothing
Parameters
- Mechanism — s (SASL_Mechanism)
- Initial_Data — ay
Start an authentication try using Mechanism, and send Initial_Data as the "initial response" defined in RFC 4422 §3.3.
Rationale:
If the HasInitialData
property is false, this indicates that the underlying protocol
does not make it possible to send initial data. In such protocols,
this method may only be used for the X-TELEPATHY-
pseudo-mechanisms (such as X-TELEPATHY-PASSWORD
),
and will fail if used with an ordinary SASL mechanism.
Rationale:
Possible Errors
- Not Available
- Network Error
- Not Implemented
Respond (ay: Response_Data) → nothing
Parameters
- Response_Data — ay
Send a response to the the last challenge received via NewChallenge.
Possible Errors
- Not Available
- Network Error
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 channels, this means that the connection manager MAY continue to connect, and MAY advance the Connection.Status to Connected.
Possible Errors
- Not Available
- Network Error
AbortSASL (u: Reason, s: Debug_Message) → nothing
Parameters
- Reason — u (SASL_Abort_Reason)
- Debug_Message — s
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. If the current status is SASL_Status_Succeeded or SASL_Status_Client_Accepted then NotAvailable is raised. Otherwise, it changes the channel's state to SASL_Status_Client_Failed, with an appropriate error name and reason code.
Possible Errors
- Not Available
Signals
SASLStatusChanged (u: Status, s: Reason, a{sv}: Details)
Parameters
- Status — u (SASL_Status)
- Reason — s (DBus_Error_Name)
- Details — a{sv} (String_Variant_Map)
NewChallenge (ay: Challenge_Data)
Parameters
- Challenge_Data — ay
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
AvailableMechanisms — as (SASL_Mechanism_List)
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
, unless none
of the available mechanisms use a password at all.
HasInitialData — b
If true, StartMechanismWithData
can be expected to work for SASL mechanisms not starting with
X-TELEPATHY-
(this is the case in most, but not all,
protocols). If false, StartMechanism
must be used instead.
This property does not affect the X-TELEPATHY-
pseudo-mechanisms such as X-TELEPATHY-PASSWORD
,
which can use
StartMechanismWithData regardless
of the value of this property.
CanTryAgain — b
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:
SASLStatus — u (SASL_Status)
SASLError — s (DBus_Error_Name)
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 channel, and connection to the server fails with an authentication failure, this error code SHOULD be copied into the Connection.ConnectionError signal.
SASLErrorDetails — a{sv} (String_Variant_Map)
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 channel, and connection to the server fails with an authentication failure, these details SHOULD be copied into the Connection.ConnectionError signal.
AuthorizationIdentity — s
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:
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:
DefaultUsername — s
The default username for use with SASL mechanisms that deal with a "simple username" (as defined in RFC 4422). If such a SASL mechanism is in use, clients SHOULD default to using the DefaultUsername; also, if the client uses the DefaultUsername, it SHOULD assume that the authorization identity AuthorizationIdentity will be derived from it by the server.
Rationale:
For example, in the simple case, if the user connects with RequestConnection({ account: "user@example.com" }) and use PLAIN with password "password", he or she should authenticate like so: "\0user\0password" and the channel will look like this:
{ "...DefaultUsername": "user", "...AuthorizationIdentity": "user@example.com }
In the complex case, if the same user is using his or her sysadmin powers to log in as the "announcements" role address, he or she would connect with RequestConnection({ account: "announcements@example.com" }) and the SASL channel would look like this:
{ "...DefaultUsername": "announcements", "...AuthorizationIdentity": "announcements@example.com }
A sufficiently elaborate UI could give the opportunity to override the username from "announcements" to "user". The user's simple username is still "user", and the password is still "password", but this time he or she is trying to authorize to act as announcements@example.com, so the UI would have to perform SASL PLAIN with this string: "announcements@example.com\0user\0password", where "announcements@example.com" is the AuthorizationIdentity.
DefaultRealm — s
The default realm (as defined in RFC 2831) to use for authentication, if the server does not supply one.
Rationale:
Types
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.
SASL_Abort_Reason — u
A reason why SASL authentication was aborted by the client.
- Invalid_Challenge (0)
- User_Abort (1)
SASL_Status — u
- Not_Started (0)
- In_Progress (1)
- Server_Succeeded (2)
- Client_Accepted (3)
- Succeeded (4)
- Server_Failed (5)
- Client_Failed (6)