gsasl-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CVS gsasl/doc


From: gsasl-commit
Subject: CVS gsasl/doc
Date: Fri, 05 Nov 2004 15:24:36 +0100

Update of /home/cvs/gsasl/doc
In directory dopio:/tmp/cvs-serv6371

Modified Files:
        gsasl.texi 
Log Message:
Fix.


--- /home/cvs/gsasl/doc/gsasl.texi      2004/10/31 20:44:03     1.88
+++ /home/cvs/gsasl/doc/gsasl.texi      2004/11/05 14:24:35     1.89
@@ -1344,14 +1344,23 @@
 @node EXTERNAL
 @section The EXTERNAL mechanism
 
-The EXTERNAL mechanism is used to authenticate a user to SASL when
-SASL is used in an environment which has already authenticated the
-user.  It is often used within TLS or IPSEC protected channels.
-
-This mechanism is only enabled in the server if you implement the
-callback below and set them in the library (@pxref{Callback
-Functions}).  It is always enabled in the client as there are no
-client callbacks.
+The EXTERNAL mechanism is used to authenticate a user to a server
+using some out-of-band authentication environment.  EXTERNAL is often
+used within TLS or IPSEC protected channels.  Note that in the server,
+you need to make sure that TLS and IPSEC actually authenticated the
+client successfully.  It is normally not sufficient for TLS and IPSEC
+to be used, since they provided anonymous modes.
+
+In the client, this mechanism is always enabled, and will send the
address@hidden property as the authorization name to the server,
+if the property is set.  If the property is not set, the empty
+authorization name is sent.  You need not implement a callback.
+
+In the server, this mechanism will invoke the
address@hidden callback to decide whether the client
+is authenticated and authorized to log in.  Your callback can retrieve
+the @code{GSASL_AUTHZID} property to inspect the requested
+authorization name from the client.
 
 @node ANONYMOUS
 @section The ANONYMOUS mechanism
@@ -1359,11 +1368,19 @@
 The ANONYMOUS mechanism is used to ``authenticate'' clients to
 anonymous services; or rather just indicate that the client wishes to
 use the service anonymously.  The client sends a token, usually her
-email address.
+email address, which serve the purpose of some trace information
+suitable for log files.  The token is not permitted to be empty.
 
-This mechanism is only enabled in the client and server if you
-implement the respectively callbacks below and set them in the library
-(@pxref{Callback Functions}).
+In the client, this mechanism is always enabled, and will send the
address@hidden property as the trace information to the
+server.
+
+In the server, this mechanism will invoke the
address@hidden callback to decide whether the client
+should be permitted to log in.  Your callback can retrieve the
address@hidden property, for example to store it in a
+log file.  The token is normally not used to decide whether the client
+should be permitted to log in or not.
 
 @node PLAIN
 @section The PLAIN mechanism





reply via email to

[Prev in Thread] Current Thread [Next in Thread]