📄 x6569.htm
字号:
<HTML
><HEAD
><TITLE
>User Authentication</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="User Registration and Authorization"
HREF="c6313.htm"><LINK
REL="PREVIOUS"
TITLE="User Registration"
HREF="x6351.htm"><LINK
REL="NEXT"
TITLE="User Registration Script"
HREF="x6787.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x6351.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 6. User Registration and Authorization</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x6787.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-6-SECT-5.3"
>User Authentication</A
></H1
><P
>There are similarities between user registration and user
authentication:</P
><P
></P
><UL
><LI
><P
>authentication must take place outside of a session context (it doesn't
really makes sense inside a session context, anyway). It is perfectly
possible to perform a user registration step followed by a user
authentication step (for any user) in the same XML stream.</P
></LI
><LI
><P
>the <TT
CLASS="LITERAL"
><query/></TT
> tag must have the name 'query'.</P
></LI
><LI
><P
>any packets sent before the authentication step (apart from user registration
packets) are queued until after the authentication step has been completed.</P
></LI
><LI
><P
>the IQ get in the <TT
CLASS="LITERAL"
>jabber:iq:auth</TT
> namespace is not
mandatory, but recommended (even more strongly than the recommendation
for the IQ get in the <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace.)</P
></LI
></UL
><P
><A
HREF="x6569.htm#JABTDG-CH-6-EX-3"
>Example 6-3</A
> shows a typical authentication process,
including the XML stream header exchange. </P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-6-EX-3"
></A
><P
><B
>Example 6-3. A typical user authentication process</B
></P
><P
>Here the authentication process immediately follows the initial
XML stream header exchange:</P
><P
></P
><P
><PRE
CLASS="SCREEN"
>SEND: <?xml version='1.0'?>
<stream:stream to='yak' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
RECV: <?xml version='1.0'?>
<stream:stream xmlns:stream='http://etherx.jabber.org/streams'
id='1ED34A55' xmlns='jabber:client' from='yak'></PRE
></P
><P
>We ask the server about the authentication methods available for
our specific user:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type='get'>
<query xmlns='jabber:iq:auth'>
<username>dj</username>
</query>
</iq>
RECV: <iq type='result'>
<query xmlns='jabber:iq:auth'>
<username>dj</username>
<password/>
<digest/>
<sequence>496</sequence>
<token>3B2DEEC0</token>
<resource/>
</query>
</iq></PRE
></P
><P
>Because we're connecting here to the server with <B
CLASS="COMMAND"
>telnet</B
>
and don't have any digest utilities handy, we decide to use the
simplest authentication method, and send our password in plaintext.
The server checks the credentials, and gives us the thumbs up. </P
><P
><PRE
CLASS="SCREEN"
>SEND: <iq type='set'>
<query xmlns='jabber:iq:auth'>
<username>dj</username>
<password>secret</password>
<resource>laptop</resource>
</query>
</iq>
RECV: <iq type='result' id='pthsock_client_auth_ID'/></PRE
></P
><P
>At this stage, we have a session.
<A
NAME="AEN6600"
HREF="#FTN.AEN6600"
>[1]</A
> </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-6-SECT-5.3.1"
>Configuration and Module Load Directives</A
></H2
><P
>The <TT
CLASS="LITERAL"
>c2s</TT
> component contains a configuration directive
related to the authorization process:</P
><P
><PRE
CLASS="SCREEN"
><service id="c2s">
<load>
<pthsock_client>./pthsock/pthsock_client.so</pthsock_client>
</load>
<pthcsock xmlns='jabber:config:pth-csock'>
<alias to='yak'/>
<TT
CLASS="USERINPUT"
><B
><authtime/></B
></TT
>
...
</pthcsock>
</service></PRE
></P
><P
>This <TT
CLASS="LITERAL"
><authtime/></TT
> tag is used to
set the time limit, in seconds, within which authentication should
be completed, starting to measure at the time the connection was made.
See <A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.3.3"
>the section called <I
>Custom Configuration</I
> in Chapter 4</A
> for more details.</P
><P
>There is also an undocumented tag <TT
CLASS="LITERAL"
><auth/></TT
>
which can be specified in the JSM instance configuration (for example
after the <TT
CLASS="LITERAL"
><register/></TT
> section) with which
you can specify an external component that is to handle authentication
in place of the standard JSM modules (<TT
CLASS="LITERAL"
>mod_auth_*</TT
>).</P
><P
>The JSM module load directives specify the modules which are to handle
authentication:</P
><P
><PRE
CLASS="SCREEN"
><load main="jsm">
<jsm>./jsm/jsm.so</jsm>
<mod_echo>./jsm/jsm.so</mod_echo>
<mod_roster>./jsm/jsm.so</mod_roster>
<mod_time>./jsm/jsm.so</mod_time>
<mod_vcard>./jsm/jsm.so</mod_vcard>
<mod_last>./jsm/jsm.so</mod_last>
<mod_version>./jsm/jsm.so</mod_version>
<mod_announce>./jsm/jsm.so</mod_announce>
<mod_agents>./jsm/jsm.so</mod_agents>
<mod_browse>./jsm/jsm.so</mod_browse>
<mod_admin>./jsm/jsm.so</mod_admin>
<mod_filter>./jsm/jsm.so</mod_filter>
<mod_offline>./jsm/jsm.so</mod_offline>
<mod_presence>./jsm/jsm.so</mod_presence>
<TT
CLASS="USERINPUT"
><B
><mod_auth_plain>./jsm/jsm.so</mod_auth_plain>
<mod_auth_digest>./jsm/jsm.so</mod_auth_digest>
<mod_auth_0k>./jsm/jsm.so</mod_auth_0k></B
></TT
>
<mod_log>./jsm/jsm.so</mod_log>
<mod_register>./jsm/jsm.so</mod_register>
<mod_xml>./jsm/jsm.so</mod_xml>
</load></PRE
></P
><P
>Each of these modules - <TT
CLASS="LITERAL"
>mod_auth_plain</TT
>,
<TT
CLASS="LITERAL"
>mod_auth_digest</TT
> and <TT
CLASS="LITERAL"
>mod_auth_0k</TT
> -
can play a role in the authentication process. As mentioned in
<A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.4"
>the section called <I
>Component Connection Method</I
> in Chapter 4</A
>, they provide different
authentication methods, these methods being reflected in their names:</P
><P
></P
><UL
><LI
><P
><TT
CLASS="LITERAL"
>mod_auth_plain</TT
>: plaintext</P
></LI
><LI
><P
><TT
CLASS="LITERAL"
>mod_auth_digest</TT
>: digest</P
></LI
><LI
><P
><TT
CLASS="LITERAL"
>mod_auth_0k</TT
>: zero-knowledge</P
></LI
></UL
><P
>There's a certain amount of flexibility you have as administrator to
determine what methods are made available on your Jabber server. If
you want to offer all three, do nothing. If you only want to offer the
<I
CLASS="EMPHASIS"
>zero-knowledge</I
> method, comment out or otherwise
remove the other two definitions</P
><P
><PRE
CLASS="SCREEN"
><!--
<mod_auth_plain>./jsm/jsm.so</mod_auth_plain>
<mod_auth_digest>./jsm/jsm.so</mod_auth_digest>
--></PRE
></P
><P
>from the list of module load directives. If you want to offer the
<I
CLASS="EMPHASIS"
>digest</I
> method, you must include the module
load directives for both <TT
CLASS="LITERAL"
>mod_auth_plain</TT
> and
<TT
CLASS="LITERAL"
>mod_auth_digest</TT
>, as the latter is merely an
extension - a 'parasite' - upon the other.</P
><P
>Let's look at each of these authentication methods in turn.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.3.1.1"
><I
CLASS="EMPHASIS"
>Plaintext</I
> Authentication Method</A
></H3
><P
>The plaintext authentication method works as you would expect, and
is the default 'lowest common denominator' method supplied
with the Jabber server. It is provided by the
<TT
CLASS="LITERAL"
>mod_auth_plain</TT
> module.</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Method</DT
><DD
><P
>The password is transmitted in the XML stream, inside the
<TT
CLASS="LITERAL"
><password/></TT
> tag in the
<TT
CLASS="LITERAL"
>jabber:iq:auth</TT
> IQ set packet, from the client to the
server in plaintext, where it is compared to the password stored, also
in plaintext, on the server.</P
><P
>When a password is changed, using a <TT
CLASS="LITERAL"
>jabber:iq:register</TT
>
IQ set as described earlier in this Chapter, <TT
CLASS="LITERAL"
>mod_auth_plain</TT
>
stores the password, as received, in the user's spool file.</P
></DD
><DT
>Advantages</DT
><DD
><P
>This method is by far the simplest to implement on the client side. It is
also useful for debugging and testing purposes as it can be used in a
connection 'by hand' via <B
CLASS="COMMAND"
>telnet</B
>, not requiring any extra
computation such as the digest and zero-knowledge methods do.</P
></DD
><DT
>Disadvantages</DT
><DD
><P
>It's insecure, on two levels. First, the password is transmitted in
plaintext across
the wire from client to server. The risk can be minimized by encrypting
the whole connection using SSL. Second, the password is stored in plaintext
on the server, which may be compromised.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-6-SECT-5.3.1.2"
><I
CLASS="EMPHASIS"
>Digest</I
> Authentication Method</A
></H3
><P
>The module that provides the digest authentication method,
<TT
CLASS="LITERAL"
>mod_auth_digest</TT
>, works in conjunction with the
plaintext module <TT
CLASS="LITERAL"
>mod_auth_plain</TT
>. It provides a way
of avoiding having to send the plaintext password across the wire.</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Method</DT
><DD
><P
>The digest method is similar to the plaintext method, in that the
password sent by the client is compared to the password stored on
the server. However in this case, the password is first encoded using
a hashing algorithm. It is encoded by the client before being sent
across the wire, and it is encoded by the server (having retrieved
it in plaintext) before being making the comparison.</P
><P
>The algorithm is the NIST SHA-1 message digest algorithm.
<A
NAME="AEN6681"
HREF="#FTN.AEN6681"
>[2]</A
>
This algorithm takes arbitrary input and produces a 'fingerprint'
or message digest of it.
<A
NAME="AEN6684"
HREF="#FTN.AEN6684"
>[3]</A
>
A random string, shared
between the client and the server, is appended to
the password before being passed to the hashing algorithm.
This random string is the value of the
<TT
CLASS="LITERAL"
>id</TT
> attribute in the server's XML stream header
response that we saw in <A
HREF="x6569.htm#JABTDG-CH-6-EX-3"
>Example 6-3</A
>: </P
><P
><PRE
CLASS="SCREEN"
>RECV: <?xml version='1.0'?>
<stream:stream xmlns:stream='http://etherx.jabber.org/streams'
id='<TT
CLASS="USERINPUT"
><B
>1ED34A55</B
></TT
>' xmlns='jabber:client' from='yak'></PRE
></P
><P
>which means, in this case, the string that will be hashed is </P
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -