[Standards-JIG] UPDATED: XEP-0178 (Best Practices for Use of SASL EXTERNAL)
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.
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 !)
> 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
More information about the Standards