Steve Holme wrote:

>> sasl: implement EXTERNAL authentication mechanism.

> * Do we need to limit this to TLS upgraded sessions - the examples in the RFC seem to use this as the EXTERNAL authentication mechanism?
No, we should not: the spec tells this is not limited to TLS. Some other external auth may be based, for example, on connecting IP address (i.e.: via a radius server or else). May be you may think of other identification ways. In practice, i've never seen EXTERNAL in non-TLS cases.

> * Are there other EXTERNAL mechanisms that can be used rather than client certificates?
See above... and imagine :-)

> * Should we implement support for an empty authentication identifier (via an empty username) as I believe is allowed in the RFC or do your modifications already cater for this?
Yes, and it's currently done this way. In TLS cases, empty username tells to use id from cert. Using a non-empty username can only be used if the server allows to delegate authorizations, such as an administrator acting for a normal user. I've never seen such an implementation, but curl supports it.

To use sasl external with the current curl implementation you have to specify URL as scheme://[user];AUTH=EXTERNAL_at_host...
Not using AUTH= or specifying a non-empty password disables EXTERNAL.

Now I would like to implement SCRAM-SHA-1 ... :-))

Cheers,
Patrick

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-01-28