[standards-jig] JEP 34 (SASL)

Jeremie jeremie at jabber.org
Wed Aug 21 18:49:06 UTC 2002


> later sets resource and establishes a session in example 10?  What 
> prevents me from sending:
> ...
> and then upon recieving <sasl:success/> sending:
> ...
> Perhaps some sort of token can be passed back in the final challenge 
> that allows me to validate the username they log in with?  Perhaps we 
> can slap a "to" on all the sasl:responses and the jabber protocol sasl 
> stuff validates that "to" and "userid" are the same?  Ideas?

That is perfectly acceptable, JEP34 is intended to use SASL to
authenticate a *stream* not a *session*, not only for users but also
components and domains, and could someday be used for not only jid's or
the jabber:* namespaces.

The use you described could be an administrator, or authorized bot,
authenticating itself via SASL which would then give it rights to create
sessions as certian other jid's.

In the case of supporting SASL, there is always the possibility that the
SASL/stream authorized identity has nothing to do with the actual jid
(other than a relationship in a database on the server), since SASL may be
authorizing a physical keycard, or an NT Domain user, etc, and the session
would be created using the jid.

Jer





More information about the Standards mailing list