Struct rsasl::SASL

pub struct SASL {
    pub global_data: Arc<HashMap<Property, Box<dyn Any>>>,
    pub callback: Option<Arc<dyn Callback>>,
    /* private fields */
}

SASL Provider context

This is the central type required to use SASL both for protocol implementations requiring the use of SASL and for users wanting to provide SASL authentication to such implementations.

This struct is not Clone or Copy, but all functions required for authentication exchanges only need a non-mutable reference to it. If you need to do several authentication exchanges in parallel, e.g. in a server context, you can wrap it in an std::sync::Arc to add cheap cloning.

Fields

global_data: Arc<HashMap<Property, Box<dyn Any>>>

Global data that is valid irrespective of context, such as e.g. a OAuth2 callback url or a GSSAPI realm. Can also be used to store properties such as username and password

callback: Option<Arc<dyn Callback>>

Implementations

impl SASL

pub fn new() -> Self

pub fn init(&mut self)

pub fn install_callback(&mut self, callback: Arc<dyn Callback>)

impl SASL

pub fn register(&mut self, mechanism: &'static Mechanism)

impl SASL

Provider functions

These methods are only available when compiled with feature provider or provider_base64 (enabled by default). They are mainly relevant for protocol implementations wanting to start an authentication exchange.

pub fn client_mech_list(&self) -> impl IntoIterator<Item = &Mechanism>

Returns the list of client mechanisms supported by this provider.

An interactive client “logging in” to some server application would use this method. The server application would use SASL::server_mech_list().

pub fn server_mech_list(&self) -> impl IntoIterator<Item = &Mechanism>

Returns the list of Server Mechanisms supported by this provider.

An server allowing client software to “log in” would use this method. A client application would use SASL::client_mech_list().

pub fn suggest_client_mechanism<'a>(
    &self,
    mechs: impl IntoIterator<Item = &'a [u8]>
) -> Option<&Mechanism>

Suggests a mechanism to use for client-side authentication, chosen from the given list of available mechanisms. If any passed mechanism names are invalid these are silently ignored. This method will return None if none of the given mechanisms are agreeable.

pub fn suggest_server_mechanism<'a>(
    &self,
    mechs: impl IntoIterator<Item = &'a [u8]>
) -> Option<&Mechanism>

Suggests a mechanism to use for server-side authentication, chosen from the given list of available mechanisms. If any passed mechanism names are invalid these are silently ignored. This will return None if none of the given mechanisms are agreeable.

pub fn client_supports(&self, mech: &Mechname) -> bool

Returns whether there is client-side support for the given mechanism.

You should not call this function to filter supported mechanisms if you intend to start a session right away since this function only calls self.client_start() with the given Mechanism name and throws away the Session.

pub fn server_supports(&self, mech: &Mechname) -> bool

Returns whether there is server-side support for the specified mechanism

You should not call this function to filter supported mechanisms if you intend to start a session right away since this function only calls self.server_start() with the given Mechanism name and throws away the Session.

pub fn new_session(
    &self,
    mechname: &'static Mechname,
    mechanism: Box<dyn Authentication>
) -> Session

Start a new session with the given Authentication implementation

This function should rarely be necessary, see SASL::client_start and SASL::server_start for more ergonomic alternatives.

pub fn client_start(&self, mech: &Mechname) -> Result<Session, SASLError>

Starts a authentication exchange as a client

Depending on the mechanism chosen this may need additional data from the application, e.g. an authcid, optional authzid and password for PLAIN. To provide that data an application has to either call set_property before running the step that requires the data, or install a callback.

pub fn server_start(&self, mech: &Mechname) -> Result<Session, SASLError>

Starts a authentication exchange as the server role

An application acting as server will most likely need to implement a callback to check the authentication data provided by the user.

See Callback on how to implement callbacks.

Trait Implementations

impl Debug for SASL

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.