[Standards-JIG] UPDATED: XEP-0178 (Best Practices for Use of SASL EXTERNAL)

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue Nov 28 16:58:04 UTC 2006


The most clear example where authzid makes sense in SASL EXTERNAL is if you 
have a client cert containing many JIDs.  You'd use authzid to choose one.

This is exactly how the XEP describes s2s to work, actually.  I'm not sure why 
c2s was written differently.

-Justin

On Tuesday 28 November 2006 8:06 am, Mridul wrote:
> Yep, you are right - I did not really consider proxying of session
> through sasl/tls.
> And the fine print difference between authorization and authentication
> (been quite a while !)
>
> Regards,
> Mridul
>
> Matthias Wimmer wrote:
> > Hi Mridul!
> >
> > Mridul schrieb:
> >> You are right about differing in authentication and authorization :
> >> hence in normal case, you could authenticate as userA thru SASL and
> >> authorize (bind) as userB.
> >
> > No you can't. On the one hand because SASL already does authorziation
> > (by RFC 2222/4422) and on the other hand because resource binding only
> > does select the resource of the client, you cannot pass an authorization
> > identity with the bind request.
> >
> >> In this specific context - you already did your auth as userA (through
> >> tls), and the bind for authorization comes at a later stage. SASL
> >> External is just indicating that you want to reuse the auth creds as
> >> negotiated by the underlying tls session and not provide another set of
> >> creds using sasl plain or digest-md5, etc.
> >
> > No.
> >
> > It is correct, that SASL EXTERNAL does not do authentication itself, but
> > indicates, that authentication, that has done using some other means,
> > should be used. But SASL EXTERNAL will always do authorization.
> > SASL EXTERNAL (RFC 4422, appendix A) will authorize you has the same
> > identity as you authenticated if you do not pass an authorization
> > identity in the SASL EXTERNAL handshake.
> >
> >
> > Tot kijk
> >     Matthias
>
> !DSPAM:456c65c5222504565035002!



More information about the Standards mailing list