Internet Direct (Indy)
|
Implements a framework supporting the Simple Authentication and Security Layer (SASL).
TIdSASL = class(TIdBaseComponent);
TIdSASL is a TIdBaseComponent descendant that implements a framework in support of the Simple Authentication and Security Layer (SASL), as described in the Internet Standards documents:
RFC 2222 - Simple Authentication and Security Layer (SASL)
The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions.
SASL commands require an argument identifying a SASL mechanism. SASL mechanisms are named by strings, from 1 to 20 characters in length, consisting of upper-case letters, digits, hyphens, and/or underscores.
SASL mechanism names must be registered with the IANA. The current list of registered SASL mechanisms can be located at:
IANA Official Simple Authentication and Security Layer Mechanisms
SASL protocol exchanges involve a series of server challenges and client responses that are specific to the requested authentication mechanism. The challenges and responses are defined by the mechanisms as binary tokens of arbitrary length. The protocol profile specifies how these binary tokens are then encoded for transfer over the connection.
After receiving the authentication command or any client response, a server may issue a challenge, indicate failure, or indicate completion. The protocol's profile specifies how the server indicates which of the above it is doing.
After receiving a challenge, a client may issue a response or abort the exchange. The protocol's profile specifies how the client indicates which of the above it is doing.
During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer. If the use of a security layer is agreed upon, then the mechanism must also define or negotiate the maximum cipher-text buffer size that each side is able to receive.
The transmitted authorization identity may be different than the identity in the client's authentication credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive an authorization identity from the client's authentication credentials.
If use of a security layer is negotiated, it is applied to all subsequent data sent over the connection. The security layer takes effect immediately following the last response of the authentication exchange for data sent by the client and the completion indication for data sent by the server. Once the security layer is in effect, the protocol stream is processed by the security layer into buffers of cipher-text. Each buffer is transferred over the connection as a stream of octets prepended with a four octet field in network byte order that represents the length of the following buffer. The length of the cipher-text buffer must be no larger than the maximum size that was defined or negotiated by the other side.
TIdSASL implements the base class used to access SASL mechanisms in the Indy library, and to perform authentication using the protocol exchange for a specific SASL mechanism.
Descendant classes are used to implement the specifics for defined SASL mechanisms and their associated protocol exchange, including:
TIdSASL and related classes (like TIdSASLEntries) are used toprovide authentication in Indy protocol clients, including:
Internet Direct (Indy) version 10.1.5
Copyright © 1993-2006, Chad Z. Hower (aka Kudzu) and the Indy Pit Crew. All rights reserved. Website http://www.indyproject.org. Post feedback to the Indy Documentation newsgroup. |