Lighttpd

+1 for this. SASL actually provides a lot of flexibility in terms of authentication and authorization back-ends. It allows for multiple mechanisms, including PAM (which gives a ton more functionality), KRB5, LDAP, SQL, and more. Cyrus SASL is probably the most well known implementation, and probably the implementation to reference; iirc, there are a couple of other SASL implementations as well, albeit less used. SASL is commonly used with mail servers, but many applications use it.

If you want to see exactly what SASL is about, RFC 4422 covers it.

if we ever do a sasl backend for mod_auth it will mostlikely be using dovecot. cyrus-sasl is just pita.

Can't you do this via a FastCGI authorizer?

sure you can. but sometimes it is pita.

darix wrote:

sure you can. but sometimes it is pita.

Why?

because you might have to patch applications that otherwise rely on the server having done basic auth.

Can't authorization be handled by a different FastCGI backend then the response part?

No, not supported right now.

For example there are some open questions regarding post content - which backend should get it? both, only one?...

The responder certainly needs it. The authorizer probably doesn't. So a first implementation might send it only to the responder.

so you don't think the auhorizer might need the login data from a form?

and no, i will not implement it in 1.x.

I didn't know any of the auth stuff supported form input. Doesn't the FastCGI spec say something about this?

https://fast-cgi.github.io/spec#roles notes that the Responder and Filter roles receives request body on FCGI_STDIN stream. The spec says that the Authorizer role receives FCGI_PARAMS stream, and does not mention FCGI_STDIN stream for the Authorizer role.

Regarding (long ago) comments:

Can't you do this via a FastCGI authorizer?

and

Can't authorization be handled by a different FastCGI backend then the response part?

Yes to both, starting with lighttpd 1.4.42 (patches will be pushed to lighttpd git master later this week)