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

Mridul mridul at sun.com
Tue Nov 28 16:06:26 UTC 2006


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
>
>   




More information about the Standards mailing list